דוח בדיקות יומי

יש מקרים ששווה להוציא דוח בדיקות יומי:

1. חשוב שכולם ידעו מה מצב הגרסה, בעיקר לקראת הסוף או כשיש בעיות.
2. לקבוע ו/או להזכיר סדרי עדיפויות.
3. כלי להניע תהליכים תקועים.
4. כלי שליטה לך עצמך, לדעת מה קורה וכו'. אם לוקח לך הרבה זמן לכתוב אותו, סימן שלא היית מעודכן.
5. כסת"ח להתרעה על בעיות.
   

לדעתי, אם אתה ממלא את תפקידך, הוא לא אמור לקחת יותר מ-20 עד 30 דקות. הרעיון אינו להעיק עליך אלא לעזור לך לנהל את הבדיקות ולשמור על תיעוד.

איך הדוח צריך להראות:

דוח מצב של <מוצר> <גרסה> מיום dd/mm/yy

חלק ראשון: קיצור מנהלים.

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

הקטגוריות של הרמזור:

1. לוחות זמנים: אדום/כתום/ירוק. אם אדום או כתום: הסבר קצר.
   
2. איכות: אדום/כתום/ירוק. אם אדום או כתום: הסבר קצר.
3. כח אדם: אדום/כתום/ירוק. אם אדום או כתום: הסבר קצר.
4. חומרה: אדום/כתום/ירוק. אם אדום או כתום: הסבר קצר.

כללי:

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

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

מצב נכון לכרגע:
build X בחדר הבדיקות.
תאריך ה-build הבא:
תאריך מעודכן של ה-build הבא:
תאריך סיום מקורי של סיום בדיקות העומס/מערכת...
תאריך סיום עדכני של סיום בדיקות העומס/מערכת...

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


חלק שני: צלילה לפרטים.

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