יום שבת, 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.


יום שני, 23 באוגוסט 2021

XRAY for Jira: סוגי הדוחות השונים (בהיי לבל)

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

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



יום ראשון, 15 באוגוסט 2021

XRAY for Jira: מהרפוזיטורי לאקסקיושן

 ה-XRAY, בהיותו בנוי בתוך הג'ירה ויורש של תכונות רבות שלה, הוא גמיש ומאפשר לעשות את אותו הדבר בדרכים שונות.

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

בשך כך בניתי סרטון הדרכה שבו ניתן לראות דרך שנראית לי מאוד נוחה שבה ניתן לעשות את התהליך הזה:

מטסט ריפוזיטורי להעביר טסטים לטסט פלן ומשם ליצור טסט אקסקיושן.



יום שישי, 6 באוגוסט 2021

XRAY for Jira: Parameterized Tests הסבר על הפיצ'ר החדש (וידאו)

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

חלק ראשון - פרמטרים רגילים:


חלק שני - פרמטרים קומבינטוריאלים:



יום שבת, 26 ביוני 2021

למה חשוב לעבור על כל הבאגים שנפתחים בכל יום

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

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

https://unsplash.com/@myleon


מדוע זה חשוב?

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

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

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