איך כותבים דוח באג שמפתחים באמת מבינים

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

המבנה שעובד

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

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

למה דוחות חוזרים עם "לא הצלחתי לשחזר"?

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

השנייה: חסרים נתונים. "ניסיתי להזמין" זה לא שחזור; "הזמנתי פריט שאזל מהמלאי בזמן התשלום" זה שחזור.

השלישית: הודעת השגיאה סוכמה במילים במקום להיות מועתקת. מזהה בקשה או שורת לוג מקצרים שעות.

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

חומרה מול עדיפות

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

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

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

שמונה טעויות נפוצות

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

מה זה אומר עליכם

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

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

שאלות נפוצות

כמה פירוט זה יותר מדי?

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

מה עושים כשלא מצליחים לשחזר בעצמי?

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

האם לכתוב בעברית או באנגלית?

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

מי סוגר את התקלה?

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

מה עושים כשהמפתח חולק על הממצא?

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