מעגל חיי הבאג בראייה המערכתית של ניהול הקוד

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

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

● Pending – באג הממתין להחלטה האם כדאי או לא לתקנו.
● More info – אנחנו צריכים מידע נוסף על מנת לקבל את ההחלטה. פותח הבאג אמור לספק את המידע הנוסף הזה.
● Triaged – יש החלטה האם לתקן, או לא, את הבאג.
● Info Received – התקבל מידע ראשוני לגבי הבאג.

בתפריט התחתון של הבאג נציין את תהליכי הבדיקה. חשוב לדעת שתהליכים אלה מועברים מה-MTM (ר"ת Microsoft Test Manager), כאשר ליד כל צעד (Step) מצוין אם עבר או נכשל. תהליכים אלה מוזרמים מה-MTM לשדה ה-Repro Steps, כדי לתת למפתח אינדיקציה היכן ובאיזה שלב נכשלו הבדיקות, ואילו בדיקות בוצעו לפני הכישלון.

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

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

לא פעם, באג נוצר כתוצאה ממשימת פיתוח או תקלה קיימת. לכן, ועל מנת לקבל תמונה כוללת טובה, חשוב לחבר אותו ל-All Links, שנמצא בתוך הבאג.

הליך הסגירה

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

סיבה נוספת שיכולה להיות להעברת הבאג למצב Resolved היא Duplicate – באג שחוזר על עצמו מספר פעמים או באג באותו נושא שמתנהל בבאג אחר.
האפשרות השימושית ביותר היא תיקון הבאג ולכן, בהעברה למצב Resolved ראוי לציין Fixed, אם הוא תוקן.

גם כשהבאג עובר ממצב Resolved ל-Closed או מ-Active ל-Closed חשוב וראוי לציין את סיבת הסגירה:

● Deferred – באג שקיים, אך נדחה למהדורות הבאות.
● Duplicate – באג שחוזר על עצמו פעמיים או באג באותו נושא שמתנהל בבאג אחר. במקרה שכזה יש לשנות את הסטטוס ל-Duplicate.
● Rejected – מצב שבו מפתח שמזהה שמדובר בבאג לא אמיתי, כזה שנפתח ללא סיבה.

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

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

הכותב הינו מומחה DevOps בעולמות מיקרוסופט בחטיבת הבדיקות של נס (V-ness).