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

באגים יש לפתוח בצורה ברורה, מדוייקת ביותר ועם מירב האינפורמציה (אבל הרלוונטית). על ה-severity אדבר מאוחר יותר.

הסיבות לכך הן:

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

לגבי 6, צריך להבין שתיאור הבאג הוא תחת האחריות שלנו, ואנו לא "עושים טובה" בכך שאנו מוציאים תוצר איכותי בתיאור הבאג, אלא שזה המקצוע שלנו וחובתנו!

הנושא:

כמובן שנושא הבאג חייב להיות מתומצת אבל גם שישה ברור מתוכו מה הבג.

זה, למשל, בסדר:

לא ניתן לשלוח הודעה קולית משורשרת ליותר מנמען אחד.

אפילו זה בסדר:

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

(ואז לפי ה-severity אפשר להבין אם המצב נדיר או לא, ואף אפשר לראות את פרטי הבאג).

אבל זה כבר לא:

יש מקרים שאי-אפשר לשלוח הודעה

וזה בטח שלא:

בעייה עם הודעות קוליות.

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

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

אז הנושא אמור להיראות כך (<> אופציונלי):

<גרסה ראשית>,<שם המוצר>,<גרסת המוצר>, <מספר build>, תיאור ממצה,<מספר הדרישה>

ברור שאפשר להוסיף לכך מידע או להחסיר, לפי המקום בו אתם פועלים.

כעת לתיאור עצמו בגוף דיווח הבאג:

Testing Activity: Functional/Load/Automatic/Free/ATP/Scratch Installation/Upgrade
אמנם הבעייה יכולה להיות אותה בעייה, אבל יש הבדל גם מבחינת הדיבאג אם זה קורה רק בעומס או בבדיקה פונקציונלית רגילה. אם זה קורה בעומס יכול להיות שמקור הבעייה הוא דליפת זכרון או המחסן בזכרון, בעוד שבעייה פונקציונלית יכולה להיות בקוד עצמו.
Impact on System/Service (more than one word) :חשוב מאוד: לפעמים הבאג נשמע לא חשוב ולכן לא יטופל במהירות, אבל לעתים לבאג כזה יש השלכות אדירות, ואותן יש להוסיף. למשל באיזו נקודה לא חשובה (בקובץ שאינו נגיש ללקוח) מספר הגרסה שגוי. לא נשמע חמור, אבל עלולות להיות לזה השפעה מכרעת בעת ביצוע שדרוג של המערכת.

יש גם לציין אם יש דרך לעקוף את הבעייה

(work around)Steps to Reproduce:1.

....

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

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

Expected Result:
איך המוצר היה אמור להתנהג. גם בשביל להבין אל מול מה שקורה בפועל, וגם בכדי שיהיה ברור מה אנו מצפים. יש למלא סעיף זה רק אל מול מסמך דרישות או כשבטוחים בכל מאת האחוזים.
Analysis:
אם יש. בודק טוב יכול לתת מידע חשוב גם אם הוא אינו מפתח, למשל ייתכן שזה קורה כיוון שהמשתמש אינו מזוהה נכון.Additional Info (if exists/relevant):

Setup:
.
.
.

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

עוד מידע חשוב
Related TCs:

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

לא הכל רלונטי לכל מקום. יש להתאים, להוריד / להוסיף.