שיפור תהליך הפיתוח והבדיקות - היכן היה אפשר למצוא את הבאג

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

אבל לא פחות חשוב לדעת אילו באגים "ברחו" גם בנקודות אחרות של התהליך:

• מסמכי שיווק;
• מסמכי מהנדס מערכת;
• מסמכי פיתוח;
• Unit tests;
• Private Integration;
• Integration Tests;
• וכמובן שלבי הבדיקה:
  Sanity;
  פרוגרסיות;
  רגרסיות;
  ועוד.

הערה: ברור שלא בכל חברה יש כל השלבים, ואני מניח שיש חברות שיש להם שלבים שלא מניתי. העיקר כאן הוא העקרון.

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

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

ההמשך הוא בהתאם לתוצאות: אם למשל הבעייה ב-Unit tests יש לבצע הערכה:
אילו איזורים חסרים? האם צריך לעדכן את כל הבדיקות או יש פערים מסויימים? האם אפשר לוותר על חלק מהבדיקות כי אין יותר סיכון בקוד הנ"ל? במקרה זה כדאי שהבודקים יעשו review על בדיקות ה-unit test ובכלל יעבדו צמוד עם הפיתוח.
אם אלו מסמכי מהנדס המערכת או השיווק: האם יש review מסודרים? האם אנשים באים מוכנים? אולי יש צורך לעזור לאנשים למצוא באגים במסמכים (זה לא קל)?
וכן הלאה.

בגדול יש חשיבות מכרעת שקל להתעלם ממנה ממציאת באג בשלב הנכון (כסף: זמן, שחיקה של בודקים, כעסים וכו').