דוח שבודק את איכות הבאגים

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

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

לוח המחוונים נמצא בג'ירה, כמו הבאגים, והדיווחים בוצעו באמצעות תוסף eazyBI.

הדוחות

אנא בדקו כל סעיף עם התמונה למטה.

• דו"ח המדד הראשון, Bugs Integrity Level, הוא צירוף של ההערכות של רוב הדוחות האחרים, מבט כללי.
  
  
• זה שמתחתיו משמאל, Dev Efficiency - Bugs per resolution with drill across, מציג רק באגים סגורים (סגורים ב-Q הספציפי הזה), לפי רזולוציה שבג'ירה.
  הירוק פירושו הרזולוציה = בוצע, כלומר הבאג היה מוצדק והקוד תוקן ונבדק. הצבעים האחרים מצביעים על באגים שנדחו (יש לנו 4 סיבות לדחייה: עובד כמתוכנן (WAD), בלתי ניתן לשחזור, סביבה וכפילות). הסיבות שאנו מודדים רק באגים סגורים/מבוצעים היא שאנו לא רוצים למדוד דחיות מוקדמות, אז אנו ממתינים עד שה- QA מאשר שזה דחה את הצדק על ידי סגירת הבאג.
  
  
• הדו"ח שלידו, Dev Efficiency - % Rejected, הוא אגריגציה של כל ארבעת הבאגים שנדחו כפי שניתן לראות משמאל.
  
  
• הדוח הבא מתחת לשניים לעיל, Average time in status - bug, מציג את הזמן הממוצע שהבאג היה בסטטוסים ספציפיים.
  אנו מתייחסים לזה רק כאינדיקציה, הוא אינו נמדד בהערכה המצטברת מכיוון שלא כל הסטטוסים נמצאים בידי QA, ולא תמיד האדם שפתח אותו אחראי לשאר הסטטוסים הרלוונטיים ל- QA.
  
  
• הדוח שלאחריו, Bugs integrity - number of missing fields, היה הקשה ביותר ליצור מבחינה טכנולוגית, השתמשנו בתוסף Jira בשם ScriptRunner.
  יש לנו תבנית בתיאור הבאגים:
  -תיאור
  -צעדים לשחזור
  -תוצאות צפויות
  -תוצאות אמיתיות
  הסקריפט בודק את קיום טקסט לאחר כל אחד מסעיפי התבנית.
  אנו מצפים שהבאג יפורט עם כמה שיותר נתונים רלוונטיים. הקו השחור הוא מספר כל הבאגים שנפתחו ב- Q הרלוונטי.
  
  
• הדוח שמתחתיו, Bugs integrity - % perfect bugs, מראה את מספר הבאגים שלא היו להם כל הבעיות הנ"ל - שהיו להם תיאור, שלבים, תוצאות צפויות וממשיות.
• בשורה הבאה, משמאל, UI bugs without visual attachment, רלוונטית לבאגים של ממשק משתמש (מבוססים על שדה מותאם אישית מוגדר מראש בשם Flow עם הערך User Flow).
  בבאגים מסוג זה אנו מצפים לקובץ מצורף ויזואלי - כמו תמונה או וידאו. אנחנו לא מצפים שיהיו לנו 100% באגים עם קבצים מצורפים, אבל פחות מ -10% זה יוצא דופן.
  
  
• דוח אחרון, מימין, unnecessary ping pong, צריך קצת הסבר על המערכת שלנו.
  המוצר שאנו מייצרים הינו מורכב מאוד, רב תחומי ומכיל עשרות רכיבים שונים. לא תמיד קל לקבוע באיזה מרכיב מדובר, ולכן QA שלנו צריך להיות (והוא כזה בפועל) מאוד מקצועי. מכיוון שהמתכנתים בדרך כלל מכירים את הרכיב שלהם אך לא רכיבים אחרים, וה-QA מכירים את כל המערכת, אי-הצבעה על הרכיב הנכון עשויה להניב תהליך ארוך ומיותר. אם הבאג נפתח בממשק המשתמש למשל, צוות ממשק המשתמש בודק, ראו שהשגיאה היא מהרכיב שלפניהם ב-flow, הם יעבירו את הבאג לאותו צוות, וזה יכול להימשך עד שהוא יגיע לרכיב הנכון . זה הרבה זמן מבוזבז.
  הדוח מונה באגים סגורים, שרכיבם בעת העברתו ל- Done היה שונה מזה שבו הוא נפתח.
  החלק הכחול מציין את הבאגים שנפתחו ונסגרו על אותו רכיב, זה מודד את המתכנתים, לא את ה- QA.