הצעה:
- לאחר שמהנדס הבדיקות פתח באג (וראה כאן) אני ממליץ להעביר אותו (assign) לראש צוות הבדיקות. זה עלול להשמע סתם כהערכת התהליך, אך זה מאוד מומלץ.
הסיבות לכך הן:
א. ייתכן שר"צ כבר מכיר את הבעייה ומישהו אחר כבר פתח באג על זה.
ב. משאיר את ר"צ מעודכן.
ג. יתכן שזה אינו באג "אמיתי".
ד. ר"צ יבחן אם הבאג אכן כתוב נכון, אם החומרה בדרגה הנכונה וכו'.
במקרה כזה צריך להיות סטטוס open. - ראש הצוות מעביר את הבאג לאחראי בפיתוח (ר"צ) או במקרים מסויימים ישירות למפתח שפיתח את הפיצ'ר, אם כי שוב - אני ממליץ שר"צ הפיתוח יעודכן בכל מקרה.
הסטטוס של הבאג צריך להיות בסוף שלב זה waiting for analysis, אלא אם ר"צ דוחה אותו והוא עובר ל-Reject והבודק מעביר ל-Agreed to Reject. - ר"צ הפיתוח מעביר למפתח הרלוונטי ב-assign.
אין צורך בשינוי סטטוס. - המפתח בודק בצורה ראשונית ואז:
א. הוא לא סבור שזה באג, ואז הוא משנה את הסטטוס שלו ל-Reject, וכמובן ממלא את הסבה לכך.
במקרה כזה על פותח הבאג להחליט אם הוא מסכים, ואז מעביר אותו לסטטוס Agreed to Reject או שהוא מעביר ל-Waiting for Analysis.
ב. הוא סבור שזה באג, מבין את הבעייה (עושה אנליזה), אך לא מתקן עדיין.
הסטטוס יהיה Analyzed. - יש להחליט אם לאיזו גרסה הבאג יתוקן לפי החומרה שלו ולפי זמן התיקון והבדיקות, ולתת לו priority.
- לאחר התיקון הסטטוס הופך ל-Resolved.
- כשהתיקון מגיע לחדר הבדיקות הוא עובר ל-Integrated.
- כאן הבודק מריץ את הבדיקה, ואז הבאג עובר ל:
א. Closed, כלומר הבאג תוקן.
ב. Reopen כלומר הוא לא תוקן.
במקרה השני זה חוזר למפתח ומשם הכל ממשיך כמו מקודם. - לאחר תיקון הבא על הבודק לבדוק אם עליו להוסיף את הסנריו לגרם לבאג לתסריטי הבדיקות.
אין תגובות:
הוסף רשומת תגובה