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

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

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

הבאג מהווה חלק אינטגרלי מה-Work Item, וכמו כל Work Item יש להפנותו (Assign To) ליישות האחראית המטפלת במקרה. לרוב, הבאג יופנה לראש צוות הפיתוח, או בהיעדרו – למתכנת האחראי על המודול.

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

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

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

התיעוד חייב להיות מאוד מדויק על מנת לתת לאיש הצוות המטפל בבעיה את התמונה הברורה ביותר ואת המידע הרלוונטי לטיפולה.

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

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

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