ניהול באגים בQA | איך לדווח נכון על באג? חלק 2

Device Specific Information

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

 Bad: No information 

 Good: GPS sensor activated, changed the orientation from landscape to portrait mode or Used the device in a sunny place or Battery state was 15% or Battery state was 100%

Software Build Version

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

 Bad: No information 

 Good: App build version 1.2.3 

Network Condition and Environment

• בחברות היי טק, לרוב, עובדים בשלוש סביבות:

–    Development: סביבת הפיתוח, הסביבה שבה כולם מפתחים במקביל. 

–    Staging: סביבה נקיה, בשביל לבדוק שהכול תקין לפני שמשחררים את הגרסה החדשה למשתמשים.

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

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

 Bad: No information or Happened on my way to work 

 Good: I was connected to a 3G network while I was walking through the city center

אם המוצר תומך בכמה שפות חשוב להוסיף מידע לגבי שם השפה

 Bad: No information 

 Good: I was using the German-language version of the app

Severity

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

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

 Bad: No information 

 Good: Critical or Medium

Bug Category

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

 Bad: No information 

 Good: Functionality or UX or Performance

Screenshot or Video

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

צילום המסך או הווידאו לא באים על חשבון התיאור! צריך לתת שם מתאים גם לקובץ שצורף לבאג.

 Bad: No screenshots or videos attached or Screenshot1.png

 Good: 01_InsertSearchTerm.png, 02_SearchResultPageWithError.png

Log Files

מתעדים את פעולות המשתמש בקובץ שנקרא קובץ לוג והוא נועד ליצור לוג (תיעוד) של פעולות מסוימות.

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

 Bad: No information provided when the app crashed

 Good: Provided the full stack trace in the bug report or Attached the log file to the report

Tester Who Found the Bug

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

מספר נקודות נוספות:

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

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

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

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

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

לחלק הראשון של המאמר:

איך לדווח נכון על באג? חלק 1