הפעם ברצוני לגעת בנושא החשוב של ניהול בקרת איכות (QA) בארגון מו"פ והאתגרים הכרוכים בכך.

נתחיל בבדיחה קלילה (ונא לא לקחת אישית): איש בדיקות קורא בתנ"ך שאלוהים מגן על הטפשים ומחליט לבדוק את זה באופן אמפירי. הוא קופץ מהחלון ושובר רגל. בעודו שוכב על האדמה נאנק מכאבים הוא חושב בשמחה: "אף פעם לא חשבתי את עצמי כטיפש אבל לא ידעתי עד כמה אני חכם!"...

מסקנה – בדיקות זה עניין כואב והגדרת איכות זה עניין מאד סובייקטיבי J 

אני רוצה להביא כעת מספר ציטוטים כחומר ראשוני למחשבה:

Software has gotten so complicated that it's become mathematically impossible to test every permutation when a product is finished

The only way to get a clean product out the door these days is to push quality assurance upstream, to make sure everyone in the company feels responsible for quality

Microrim president David Hull.A

A defect that costs $1 to fix on the programmer’s desktop costs $100 to fix once it is incorporated into a complete program and many thousands of dollars if it is identified only after the software
has been deployed in the field

Building a Better Bug Trap – The Economist June 2003 

האם גם אתם מרגישים שבמירוץ להגדלת המוצר והפיצ'רים, האיכות נשארת קצת יתומה מאחור? האם אתם מחפשים דרכים יצירתיות להגדיל איכות בלי להכפיל את כמות הבודקים ואת כמות המעבדות? אתם לא לבד... ולא – זאת לא בעייה קלה.

למנכ"ל טיפוסי של חברה קשה להשלים עם עצם קיומם של אנשי בדיקות. מנהלי מו"פ לא מעטים נתקעים במקום הזה שהופך לנקודת חיכוך מתמדת. הסיבה להתנגדות זו היא פשוטה למדי ולא נעים להודות, גם הגיונית. מנכ"ל מודד ונמדד לפי תוצאת שורה תחתונה – הכנסות מינוס הוצאות תפעוליות. מהנדס פיתוח חדש מגדיל ישירות את היצע החברה ופוטנציאל המכירות ולכן אמור לשפר את השורה התחתונה למרות עלותו. איש בדיקות לעומת זאת גורע מרווחיות החברה כי הוא לא "מייצר". מש"ל...

האם זה ניתוח מדויק? לא לגמרי, אבל יש בו גרעין אמת... בואו ננסה לשים מספר הצהרות על שולחן הניתוחים:

·         איכות היא עניין מערכתי וחוצה גבולות – היא מתחילה באיכות הדרישות, ממשיכה לאיכות תכנון הקוד, איכות הקוד עצמו, איכות התהליכים וכו' – נסיון לחפש נקודת עוגן אחת או דיסיפלינה אחת האחראית באופן בלעדי "לאיכות" תידון לכישלון מוחלט.

·         באגים ותוכנה ימשיכו כנראה להיות קשורים בקשרי משפחה מדרגה גבוהה (עם מקדם אהבה גבוה). האתגר הוא בניפוי מוקדם של באגים פשוטים כך שאנשי הבדיקות יתמקדו במציאת הבעיות המערכתיות בעיקר – מקום בו הם מביאים את התועלת ואת כישוריהם היחודיים למקסימום.

·         תהליך מציאת הבאגים ווידוא איכות  הגירסה הוא תהליך ארוך וסיזיפי. האתגר הוא פישוט התהליך, קיצורו, הפיכתו ליותר מדויק וניתן לחזרה בלי שגיאות, והקטנת כמות המשאבים בביצועו למינימום

עכשיו ננסה להכניס קמת טרמינולוגיה וסדר לתוך באלאגן מושגי האיכות הרווחים

Quality Control– אוסף פעילויות שמטרתם להעריך את איכות המוצר. תהליך בדיקת המערכת במטרה למצוא באגים (כולל התהליכים הרלוונטיים כמו כתיבת תכנית בדיקות)

Quality Assurance – אוסף פעילויות שמטרתם לוודא שתהליך הפיתוח ו/או תחזוקת המוצר טובים דיים כדי להגיע בסוף הדרך למוצר איכותי       

QA מול Testing – מאמר מבוא טוב ששווה מאד קריאה אפשר למצוא ב- http://www.cmcrossroads.com/index2.php?option=com_content&do_pdf=1&id=6782

השורה התחתונה מהמאמר שחשוב מאד להבין היא שרוב הארגונים לא באמת עושים QA למרות שברובם יש קבוצת QA... אני מקווה שהמאמר לעיל נותן טעם לטענה מדוע QA  כל כך חשוב ויכול לחסוך זמן ועלויות לארגון ולמה הוא חוצה גבולות דיסיפלינות בארגון פיתוח.

אז בפעם הבאה שהתשובה שאתם מקבלים לשאלה "מה היא מטרת QA “ היא - "למצוא כמה שיותר באגים", אני מציע לחשוב על זה שוב. משהו בחשיבה צר... נסו להבין היכן הבאגים נולדים (רמז: תהליכים) ולא איך לחפש אותם בסוף הדרך.

אוקי – אז איך כל הארגון כולו יכול להיות שותף יותר טוב בשיפור האיכות בשלבים מוקדמים? הינה מספר נקודות לבחינה:

·         Unit Testing – האם ארגון הפיתוח משתמש בכלי זה בצורה אפקטיבית? האם יש הסכמה לגבי גבולות הגזרה בין unit  ל-functional testing? לינק למאמר: http://www.mobilein.com/WhitePaperonUnitTesting.pdf

·         Code Reviews ו-Code Inspections: לינק לאוסף מאמרים בנושא: http://www.smartbearsoftware.com/about-docs.php

·         האם הארגון מגדיר ומשתמש במטריקות (metrics) למדידת מטרות ושיפורים? מטריקות הן כלי חשוב אך יכולות להפוך לחרב פיפיות בשימוש לא נכון (ולעודד כתוצאה מכך התנהגויות לא רצויות). דוגמא לכך היא מדידת פרודקטיביות של איש בדיקות לפי כמות הבאגים שהוא מוצא ביחידת זמן או מדידת איש פיתוח לפי כמות הקוד שמיוצרת ליחידת זמן (רמז: התחילו למדוד כמות קוד שנמחקת, זהו מדד יותר טוב). מאמר טוב בנושא נמצא ב- http://www.hyperion.com/leaders/insights/organization_culture/metrics.cfm

·         איכות ה-review  של מסמכים בין דיסיפלינות שונות בשלבים התחלתיים של הפיתוח (design review, test plan review, requirements review)

·         איכות תהליך איסוף הדרישות למוצר ואימותם

זכרו את העיקרון הפשוט – ככל שבעיות איכות ימצאו בשלב מוקדם יותר, עלויות התיקון ירדו באופן אקספוננציאלי (זה זמן טוב להסתכל שוב בציטוטים שהבאתי לעיל).  

עיקרון זה נקרא גם: Pushing quality upstream (דחיפת איכות במעלה הזרם)... האמת ששמעתי מושג זה בפעם הראשונה במהלך עבודתי במיקרוסופט ארה"ב ותמיד הנחתי שזה קשור איכשהו לעולם דגי הסלמון בצפון מערב היבשת שחותרים בעוז במעלה הזרמים בעונת הרבייה (אבל אם מישהו יודע מה הסיפור האמיתי אשמח לשמוע J). 

הנושא האחרון שאגע בו בפוסט זה הוא לגבי מהות העבודה של איש QA  בארגון פיתוח. ארגונים רבים מבדילים בין איש ה-QA שמטרתו תכנון וביצוע בדיקות מוצר מתוך הבנה עמוקה של "מה המוצר עושה" ו-"מה יחסי הגומלין שלו עם הסביבה העסקית שבה הוא פועל" ומהנדס הבדיקות (test engineer) שמטרתו להביא כלים ותפיסה הנדסית לעולם הבדיקות (במקרים מסויימים תוך התפשרות על ההבנה העיסקית שהוא מביא איתו).

במיקרוסופט נושא הנדסת הבדיקות מפותח מאד. אני ממליץ לקרוא את הבלוג הבא לקבל רושם ראשוני: http://blogs.msdn.com/jobsblog/archive/2004/05/27/143419.aspx

אז איזה סוג אנשי בדיקות אני צריך בארגון ה-מו"פ שלי? התשובה הקצרה – גם וגם!

·         הבנה עסקית היא קריטית בארגון הבדיקות כי בסופו של יום ארגון זה אמור לתת את התשובה לשאלה הבאה: "האם המוצר נכתב ועובד בהתאם לספסיפיקציות העסקיות והאם הוא משרת את צרכי הלקוח?"

·         הזנחת כלים הנדסיים בתכנון וביצוע הבדיקות יגרום להכפלות משאבים. בדיקת הגרסה תתארך מאד בשל אופי הבדיקות הידניות מה שיפגע ביעדי החברה כולה. יכולת החזרה על בדיקות בצורה מדויקת נפגעת אם הן מבוצעות בצורה ידנית בלבד. לבסוף כלים הנדסיים משפרים את יכולת המעקב והחיזוי בשלב האחרון של פיתוח המוצר – stabilization period.

·         שילוב חכם של שתי סוגי הדיסיפלינות מעודד QA אמיתי כיוון שהוא מאפשר להתמקד בתהליכים ואיכות המוצר בתרחישי האמת ולהפוך את המשימות "הסיזיפיות " (הקמת מעבדות, הרצת בדיקות, זיהוי כשלונות, ניטור, ואפילו פתיחת באגים) לממוחשבות תוך חסכון ניכר בכוח אדם.

·         הפרדה בין הקבוצה המפתחת בדיקות אוטומטיות לבין קבוצה האחראית על מעבדות והרצת הבדיקות מאפשרת יעילות ומיקוד. מהנדס בדיקות שצריך גם לפתח וגם להריץ הוא לא יעיל (וחמור מכך – מתוסכל)

·         קיצוניות יכולה להיות מסוכנת כאן. המטרה להפוך את כל ארגון הבדיקות לממוחשב ושימת דגש רק על הנדסה מרחיקה את תשומת הלב מההבנה העסקית של המוצר והלקוחות ולכן השילוב הוא חשוב. יש להבחין בין בדיקות הרגרסיה ו-"בדיקות העשן" (שצריכות להיות אוטומטיות ככל הניתן ומורצות לעיתים תכופות) לבדיקות מסוג exploratory testing שמטרתן לשוטט בצורה מובנה במוצר ולחפש בעיות בדרך עבודתו

·         Code coverage analysis

·         Model based testing

·         Functional and UI test automation (e.g. QTP)

·         Test case manager (e.g. TestDirector)

·         Load test (e.g. LoadRunner, WebLoad)

·         Static analysis (e.g.  Microsoft PreFast)

·         Fault injection

אתם מוזמנים להצטרף לקהילת המו"פ הראשונה בישראל: randd.cafe.themarker.com