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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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


 

עוד בנושא...

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