תהליכי פתיחת באג

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

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

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

מהו דיווח הבאג (bug report)?
דיוח הבאג הינו מסמך טכני המתאר כשל ב-SUT שעלול לסכן את איכות חווית המשתמש.

מהי מטרת דיווח הבאג?
מטרת הדיווח היא להגדיר את הבעייה, את ההשפעות שלה, את המשקל שלה, ולתת כמה שיותר כלים לפיתוח לתקן את הבעיות.
דיווח יעיל יפחית את כמות הבאגים שלא תוקנו באמת (re-open), יגביר את מהירות תיקון הבאג, יגדיל את ההערכה והאמינות לצוות הבדיקות, יחזק את השיתוף בעבודה.

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

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

תהליך פתיחת הבאג:

לשון זכר, הכוונה לכל המינים שיש.

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

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

אז הרצנו בדיקה והתוצאה שונה מהצפוי. מה עושים?

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

אם בין התוצאה של הבדיקה לבין הכתוב בסמכי הדרישות יש אי-תאימות, ברור שיש כאן באג! ייתכן שבתוכנה, אולי במסמך.

יש לדווח על בעיית של איבוד מידע או התקרשות (מהמילה crash) של המערכת אף אם חד-פעמית. ייתכן שמדיווח טוב יהיה לפיתוח מספיק מידע להבין את הבעייה! (יש לציין: לא משתחזר).

זכור, אתה הלקוח הראשון של המערכת!

2. שחזור. קודם כל, חזור שוב על הצעדים וודא שאתה מקבל את אותן התוצאות. תעד את הצעדים בצורה מדוייקת.

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

למשל אם הייתי בודק את ה-word, לכתוב הכנס את הטקסט הבא:
אני אוהב לשמוע את ג'ורג' הריסון.
ולשמור, ואז תקבל הודעת שגיאה X.
זה בודאי לא מספק. צריך לבודד את הבעייה עד שנבין שהגרש בעייתי, ואז האם תמיד או רק במקרים מסויימים (בתוך מילה, רק בגופן ספציפי, במערכת הפעלה מסויימת), והאם יש work around.

פעמים רבות תהליך האלימינציה הוא זה שעוזר במציאת הבעייה. פשוט מוציאים אחד אחרי השני גורמים שהשתפו בתהליך (ייתכן כמה במכה בכדי להגביר את היעילות) עד שנגיע למקור הבעייה.
למשל זכורה לי בעייה באפליקציה שבדקתי הכוללת אינטגרציה ל-outlook. לאחר שימוש ממושך בכל הפונקציונליות הקיימת היא חדלה לתפקד.
מה שעשיתי היה להריץ באופן אוטומאטי של פעולה בנפרד עד שפעולה ספציפית גרמה לבעייה.
התברר ששימוש בה מעל ל-31 פעמים ירסק אותה. זה היה מסובך מבחינת מציאת הגורם.

יש לצרף לוגים מתאימים, רשומות בבסיס הנתונים.

4. נסה לעשות הכללה של הבעייה. אם למשל ראינו בדוגמא למעלה שהגרש בעייתי, נסה לראות מה לגבי תווים אחרים.

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

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

הנה כמה נקודות חשובות לגבי כתיבת הדיווח:
-היה מדוייק ותמציתי.
-היה ענייני- בלי הומור או האשמות (כגון: שוב הבעייה ה... חזרה).