מדריך מלא לכתיבת Bug Report מקצועי

פורסם ע"יdinraפורסם בUncategorizedתגים: , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

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

1. מהו Bug Report איכותי?

דיווח באג איכותי הוא כזה שמקיים שלושה עקרונות ברזל:

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

2. אילו שדות חייבים להיות בדיווח?

כדי שלא לפספס אף פרט קריטי, כל מערכת לניהול משימות (כמו Jira, ClickUp או GitHub Issues) צריכה לכלול את השדות הבאים:

  • ID (מזהה ייחודי): נוצר אוטומטית על ידי המערכת (למשל, PROD-1234).
  • Title / Summary (כותרת): תיאור קצר ומדויק שמסביר מה קרה, איפה ומתי. (מבנה מומלץ: [רכיב/עמוד] - מה הבעיה - באילו תנאים).
  • Environment (סביבת עבודה): המקום שבו הבאג קרה.
    • סביבה: Production, Staging, Dev.
    • דפדפן/מערכת הפעלה: Chrome v120, iOS 17.4, Android 14.
    • סוג מכשיר: iPhone 15, Desktop.
  • Severity (חומרת הבאג): ההשפעה הטכנית של הבאג על המערכת (Critical, Major, Minor, Low).
  • Priority (עדיפות): מתי צריך לתקן את הבאג (High, Medium, Low). נקבע לרוב בשילוב עם מנהל המוצר.
  • Steps to Reproduce (צעדים לשחזור): הרשימה המדויקת של הפעולות שמובילות לבאג.
  • Expected Result (תוצאה צפויה): מה המערכת אמורה לעשות לפי האיפיון.
  • Actual Result (תוצאה בפועל): מה המערכת עושה ברגע הנתון.
  • Attachments (קבצים מצורפים): צילומי מסך, הקלטות וידאו וקבצי לוג.

3. כיצד לכתוב Steps to Reproduce (צעדים לשחזור)

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

טיפים לכתיבה נכונה:

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

4. Expected Result מול Actual Result

ההפרדה הזו קריטית כדי להבהיר למפתח מדוע זו בכלל נחשבת תקלה.

  • Actual Result (התוצאה בפועל): מתארת את המציאות השבורה. עליה להיות עובדתית, אובייקטיבית וללא ספקולציות.
    • דוגמה: "מופיעה שגיאת שרת 500 והמשתמש נשאר באותו עמוד."
  • Expected Result (התוצאה הצפויה): מתארת את ההתנהגות התקינה, רצוי בהתבסס על מסמך איפיון (PRD) או לוגיקה עסקית.
    • דוגמה: "התשלום מבוצע בהצלחה, והמשתמש מועבר לעמוד תודה (Success Page)."

5. צירוף Screenshots ו-Logs (עזרים ויזואליים וטכניים)

תמונה אחת שווה אלף מילים, והקלטה שווה אפילו יותר.

  • Screenshots (צילומי מסך): אם מדובר בבאג ויזואלי (UI), צלמו את המסך. מומלץ בחום: להוסיף חץ אדום או מסגרת שמדגישה את האזור הבעייתי.
  • Screen Recording (הקלטת מסך): עבור באגים של תהליך (Workflow) או באגים שקשה להסביר במילים, הקליטו סרטון קצר (10-15 שניות) שמציג את הצעדים עד לשחזור.
  • Console & Network Logs: אם מדובר בבאג פונקציונלי (משהו לא עובד בלחיצה), פתחו את ה-DevTools (F12), צלמו את השגיאות האדומות ב-Console, או ייצאו קובץ HAR משונית ה-Network. זה מקצר למפתחים את זמן איתור הבעיה בקוד במאות אחוזים.

6. דוגמאות: איך לעשות ואיך לא לעשות

❌ דוגמה לבאג שנכתב בצורה פחות טובה (Bad Bug Report)

כותרת: האפליקציה קורסת בתשלום!!!!!

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

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

דוגמה לבאג שנכתב בצורה מצוינת (Good Bug Report)

Title: [Checkout] – App crashes with a 500 Error when user submits a coupon code containing special characters.

Environment: Staging | Chrome v124.0 | Desktop (MacOS) Severity: Major | Priority: High

Steps to Reproduce:

  1. Navigate to the shopping cart page: https://staging.pcs365.co.il/cart
  2. Add any item to the cart.
  3. In the "Coupon Code" field, enter the following value: SALE#2026!
  4. Click the "Apply Coupon" button.

Actual Result: The page freezes for 3 seconds, and then a "500 Internal Server Error" message appears. The item is not discounted.

Expected Result: The system should validate the input. If the coupon is invalid/contains unsupported characters, it should display a user-friendly error message: "Invalid coupon code format".

Attachments:

  • [Attached: screenshot_error_500.png] – showing the red error banner.
  • [Attached: console_logs.txt] – containing the uncaught exception from the network tab.

לסיכום

דיווח באגים מקצועי הוא כרטיס הביקור של איש ה-QA ומפתח מקצועי. ככל שתשקיעו בכתיבה מובנית, ברורה ומגובה בנתונים, כך זמן סבב הפיתוח (Time-to-Fix) יתקצר, והיחסים בין צוותי הבדיקות לצוותי הפיתוח יהיו פרודוקטיביים וטובים הרבה יותר.

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

קורס לבדיקות תוכנה מדויק

לעבוד מהבית כבודק תוכנה עם FIVERR >> לחץ כאן

כתיבת תגובה