קודם כל נשאלת השאלה: מאיפה באים באגים? 🙂

מאיפה באים באגים?

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

עלות תיקון באגים

ככל שמתקדמים יותר בשלבי מחזור חיי הפיתוח (SDLC), עלות תיקון הבאגים עולה. לכן חשוב להתחיל QA מוקדם ככל האפשר.

Software Problem Report (SPR) – דיווח באגים

בדיווח באג חשוב לכלול:

• תיאור ברור של הבעיה

• צעדים לשחזור (Steps to Reproduce)

• תוצאה צפויה מול תוצאה בפועל

• Severity (חומרה – עד כמה הבאג משפיע על המערכת)

• Priority (עדיפות – מתי כדאי לתקן)

  נהוג לנהל באגים במערכת מעקב כמו Jira.

מחזור חיי באג (Bug Lifecycle)

• Open / New – הבאג נפתח ונרשם.

• Rejected – צוות הפיתוח קובע שזה לא באג/לא רלוונטי.

• Duplicate – נמצא שהבאג כבר דווח בעבר (כפילות).

• Fixed – הפיתוח תיקן את הבאג.

• Retest – QA מבצע בדיקה חוזרת כדי לוודא שהתיקון עובד.

1. אם הבאג עדיין קיים אחרי תיקון → Reopen.
2. אם הכול תקין בבדיקה החוזרת → Closed.

הערה: לאחר תיקון באג, מעבר ל־Retest, מבצעים גם בדיקות רגרסיה כדי לוודא שהתיקון לא שבר חלקים אחרים במערכת.

מומלץ לקרוא על בדיקות שפיות (Sanity Testing).