יום שבת, 30 באוקטובר 2021

XRAY for Jira: סטטוס הרצות הטסטים לפי פולדר בטסט פלאן

 אם אתם רוציו לראות את הסטטוס של ריצת בדיקות לא רק באופן כללי אלא לכל תיקיה:

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


יום שישי, 29 באוקטובר 2021

XRAY for Jira: חיווי איכות הטסט קייס (סידור מותאם על ידינו)

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

השתמשנו בתוסף של ג'ירה ScriptRunner כדי לעזור עם זה.

אלו האינדיקציות:

  • מספר הסטפים (חייב להיות בין 4 ל-12 סטפים).
    צבע: אם אין סטפים - אדום, אם יש פחות מ-4 או יותר מ-12 - כתום.
  • קבצים מצורפים (לא חובה, המלצה חמה).
    צבע שחור.
    תיאור (description) של הטסט.
    צבע כתום.
  • סטטוס של הטסט (לא סטטוס הריצה, אם עברה או לא, אלא הסטטוס של ה-issue type) - צריך להיות מאושר (כלומר עבר ביקורות פנימיות וחיצוניות).
    צבע אדום.

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

חיווי איכות הבדיקות


יום שישי, 15 באוקטובר 2021

דוח על הזדקנות הבאגים Bugs - Aging reports

ישנן שתי דרכים שאני יודע לחשב הזדקנות באגים:

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

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

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

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



יום שבת, 2 באוקטובר 2021

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

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

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

לוח המחוונים נמצא בג'ירה, כמו הבאגים, והדיווחים בוצעו באמצעות תוסף 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.


רשומות פופולריות