כיצד פותחים באג בצורה נכונה ?
מאת : נתי הורנשטיין , עורך אתר QAtest
בשבועיים הקרובים אנו עומדים לסיים בדיקות לגרסה,
הגרסה החמישית השנה, לא כולל העברות ליצור של תקלות דחופות
ו"חוצה גרסה" ותיקוני חרום ......שחייבים ....
במהלך הבדיקות מתגלים באגים אשר מתועדים ועוברים לטיפול של צוות הפיתוח.
לפני שנדבר על אופן תיאור התקלה החלק החשוב ביותר,להלן מספר נקודות החשובות לכל העוסקים בבדיקות ונדרשים לתעד את הבאג/תקלה לגורם אחר בתהליך הפיתוח: שדות חובה לכל תקלה:
- טופס – תיעוד בטופס תקלה.
- Severity (חומרה) – דרוג חומרת התקלה (קלה, בנונית, חמורה, קריטית).
- Priority (עדיפות) – נמוכה, בנונית, גבוה.
- סיווג התקלה – סיבת פתיחה: בעיית אפיון/דרישה, קידוד, הצעות לשיפור, הצעות לשינוי.
- שם פותח התקלה.
- שם אחראי לטפל בתקלה.
- סטאטוס התקלה.
- מספר התקלה – נומראטור שנותן באופן אוטומטי מספרי תקלות באופן רץ (כך שלא יהיה מצב לכפילות).
- תאריך פתיחת התקלה.
- תאריך סגירת התקלה.
- שדות לציון סביבת הבדיקה – סימון סביבת תוכניות, סימון סביבת DB.
- נושא התקלה.
- מספר גרסה שנבדקת.
- מספר ישות נבדקת – מספר לקוח (ערך חד ערכי).
עד עכשיו מפינו והכנסנו חלק חשוב מהנתונים לצורך זיהוי של התקלה עכשיו לאחר שהכנסנו את הכול הגענו לחלק החשוב ביותר והוא תיאור התקלה, לכאורה פעולה פשוטה אך על זה יקום ויפול דבר ! תיאור התקלה:
התיאור חייב להיות בנוי STEP BY STEP (צעד אחר צעד):מה הם המסכים שעברנו עד קבלת הודעת השגיאה ?מהי הפעולה שבוצע לפני קבלת התקלה/הודעת השגיאה ?איך נוצרה התקלה ? מה הם הכפתורים שנלחצו לפני קבלת התקלה ?מתי בוצע הפעולה ? שעה מדויקת!הסבר למה זו תקלה ? תיעוד ע"י צילום מסכי המערכת.
תיאור כזה יעזור לגורם שלא חווה את התקלה להבין בדיוק מה קרה לבודק/משתמש במערכת.
בנוסף, תיאור מדוייק יכוון אותו לאזור שבו דרוש לבצע את התיקון בקוד. כמובן שמנתוני התקלות המדווחות, בסוף כל גרסה יש להפיק דוח סיכום בדיקות לגרסה S.T.R - Software Test Result (מסמך מתאר תוצאה של הרצת סבב בדיקות על המוצר).הדוח מציג את סיכום התקלות, חומרת התקלות, זמני טיפול ומהווה סגירה ניהולית לכל תהליך הבדיקות שנעשה.