מתודולוגיה ותהליכי בדיקות | נטליה רחמני

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

במהלך תחקיר האירוע שיצרתי עלו השאלות הבאות:

א. איך מחלקת ה-QA מונעת הישנות של מקרים דומים?

ב. מה התהליך שיבוצע ב-QA כדי לשפר את האיכות בעקבות הבאגים האלה?

הדרך בה בחרתי לסגור את הפערים הייתה הפעלת תהליך מתודולוגי מובנה כחלק מכל גירסה, תהליך המכונה “escaped bugs”. לאחר סיום התחקיר התחלנו ביישום המתודולגיה כחלק מבדיקות הגירסה והפעלתה בהתאם לצורך.

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

מהו תהליך Escapes bugs ומה הגדרתו המתודולוגית?

Escaped bugs הם סך התקלות שנמצאו בייצור / פגמים שנמלטו מהמעבדה. מדד התקלות שנמלטו הוא מדד פשוט הסופר את מספר התקלות עבור גירסה נתונה שנמצאו לאחר שחרור הגירסה. אלו תקלות אשר מתגלות על ידי הלקוח, שלא אותרו על ידי צוות הפיתוח /QA .

 לפני שארחיב על הדרכים לשיפור איכות המוצר באמצעות התהליך הנ”ל, ארצה לגעת במספר נקודות ולהבהיר את חשיבות הבאגים שמגיעים לייצור:

1. תקלות שנמצאו בייצור מהוות פוטנציאל לנזק למוצר/חברה בין אם באספקט של איכות המוצר ובין אם באספקט של מוניטין החברה בסוגיית האיכות.
2. חלק מהתקלות שנמצאו בייצור דורש תיקון מיידי: כל סבב תיקונים דורש הוצאת פאטצ’ או הוט פיקס. מעבר לביצוע התיקון על ידי צוותי הפיתוח, ידרוש סבב כזה גם בדיקות של צוות האיכות, אריזה של חבילת התיקונים, בדיקת התקנה והתקנה אצל הלקוח. מלבד זמן ושעות עבודה של צוותי החברה, סבבי התיקונים דורשים גם עבודה מצד הלקוח עצמו.
3. כל סבב פיתוח ובדיקות של תיקונים עשוי לגרום לעיכוב בזמנים בפיתוח שוטף של מוצר.

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

יישום התהליך

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

שלבי יישום התהליך

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

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

4. מעבר על הבאגים יחד עם הבודקים תוך שימת דגש על הסיבות והגורמים לאי איתורם ואילו צעדים הבודקים צריכים לעשות בכדי לצמצם את כמות הבאגים הלא מאותרים. חשוב לבצע בחינה זו כצוות בכדי שהבודקים יחשפו לשלל הסיבות והגורמים השונים לבאגים מסוג זה.
5. יצירת טבלה על פי הפרמטרים למדידה - מצ"ב דוגמה לטבלה גנרית אשר לדעתי תתאים ברוב המקרים:

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

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

להלן דוגמאות לסיבות נפוצות לבאגים לא מאותרים:

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

זוהי רשימה חלקית של סיבות ובכל מערכת הסיבות עלולות להשתנות.

לסיכום

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