בדיקות והבטחת איכותMenu

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

סקירה של Bug lifecycle in software development and testing

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

מידע חשוב נוסף מתייחס להליך של הערכת חומרה, עדיפות, סיכון, משאבים ומאמץ לתקן את הבאג. שדה זה נועד לעקוב אחרי המצב של תהליך קבלת ההחלטות. נתונים אלה ניתנים למילוי בשדה 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 בעולמות מיקרוסופט בחטיבת הבדיקות של נס טכנולוגיות

 

עוד בנושא...

עוד פרסומים בנושא אשר עשויים לעניין אותך