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

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

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

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

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

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

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

בואו ונגיע לשאלה של איך דוח על באג צריך להראות ומה המידע שהדוח צריך להכיל.

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

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

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

עכשיו נעבור לתוכן של הדיווח על באג.

Bug ID

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

 Bad: 123 is a unique ID, but you might have several projects whose IDs are the same

 Good: AppXYZ-123 is good because you’re combining an ID with a project abbreviation and a number

Description

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

 Bad: The app crashed, White page, Saw an error, Bug 

 Good: Error Code 542 on detail message view or “Time-out when sending a search request

Steps to Reproduce

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

 Bad: I tried to execute a search 

 Good: Start the app and enter ‘Mobile Testing’ into the search input field. Press the search button and you’ll see the error code 783 on the search result page header

Expected Result

בחלק הזה מתארים מה צריך היה לקרות אם הבאג לא היה קורה.

 Bad: It should work or I didn’t expect it to crash 

 Good: I expected to see a search results page with a scrollable list of 20 entries

Actual Result

•    מה קרה בזמן שהבאג קרה?

•    מה קורה בפועל בגלל הבאג?

•    מה השתבש?

 Bad: It just won’t work

 Good: The search results page was empty or I got the error code 567 on the search results page 

Work-around

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

 Bad: I found a work-around 

 Good: If you put the device into landscape mode, the search button is enabled and the user can search again

Reproducible

האם הבאג משתחזר כל הזמן? האם הוא קורה כל הזמן? מה נעשה אם הבאג משתחזר רק ב – 20% מהמקרים? חשוב לתת למפתחים כמה שיותר מידע ובשביל למנוע מצב שהמפתחים לא מצליחים לשחזר אותו ומעבירים אותו למצב: Can’t be reproduced

 Bad: Sometimes 

 Good: The bug occurs two out of ten times 

Operating System, Mobile Platform, and Mobile Device

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

 Bad: On Android or On iOS

 Good: Android, Version 4.1.2 Google Nexus 4 or iOS, Version 6.1 iPhone 4S 

לחלק השני של המאמר:

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