שילוב מדדים עם הערכות: איך לנטר את היעילות של תהליך הבדיקות ודרך חדשה לסיווג באגים

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

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

למה בעצם לנטר את היעילות של הבדיקות?

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

- האם הבדיקות אכן מוצאות את הבעיות העיקריות של המוצר? למשל אל מול מה שנמצא ע"י לקוחות.

- האם הבודקים מכירים את המוצר מכל מיני בחינות - טכנית, מוצרית, שינויים ועוד? למשל כמות הריג'קטים.

- האם הבאגים אפקטיביים? למשל אם אין הרבה דיווחים על באגים שבפועל מצביעים על תפקוד נורמלי של המערכת (ה-Works As Designed) כנראה שהם אפקטיביים בממד זה.

- האם סבבי הבדיקות אורכים פרקי זמן סביר?

בכדי לענות על שאלות אלו אנו עשוים להשתמש במדדים והערכות, כלומר אנו מנטרים את מצב העניינים.

לפני שקופצים למדדים והערכות, בואו קודם נדון בשאלה: למה אנחנו רוצים להעריך או לנטר את היעילות של הבדיקות?

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

ניטור זה לא הכל!

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

• מה ההיקף של הבדיקות? האם כל מה שצריך להיבדק נבדק (ולהיפך)?

• האם אנו משתמשים בכל הכלים הנדרשים למצוא באגים (למשל סימולטורים)?

• מה המצב של הפיתוח ככלל? למשל נהוג לעשות קוד ריוויו?

• אוטומציה - קיימת? בכל הרמות? אפקטיבית?

++ בעצם כל מה שקשור בניהול נכון של הפיתוח כולל הבדיקות.

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

מדדים

מהו מדד? לפי וויקי: 

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

Photo by Ishant Mishra on Unsplash

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

דוגמה למדד הוא מספר הבאגים שהגיעו מהשטח (אסקייפס), ואם הם עוברים יעד שנקבע מראש, נניח 7% מול הבאגים בגרסה שנמצאו,  כדאי להבין איך זה קרה (למשל ראו כאן: https://www.testerschoice.pro/single-post/Escapesanalysisandretrospective ). כמובן שזה תהליך שלא נועד כדי למצוא "אשמים" אלא לעזור לעצמנו להשתפר. אם המספר הגבוה של האסקייפס נובע מכך שחסרים לנו בבדיקה מכשירי מובייל נפוצים בשטח - בואו נוודא שאנחנו פותרים את זה בין אם ברכישת מכשירים, קראוד טסטינג ועוד.

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

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

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

הערכה איכותית

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

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

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

שילוב ניטור כמותי ואיכותי

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

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

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

יעילות הבאגים

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

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

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

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

אז מה אנחנו מעריכים?

סיווגי דיווחי באגים לפי איכות הבאג

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

המידע ברור

האם הבאג כתוב בצורה ברורה? אם לא מצבנו לא טוב מכמה סיבות: 

1. זו יכולת בסיסית אצל בודקים, אם היא לא באה לידי ביטוי צריך לבדוק למה.

2. היא יכולה להצביע על השקעה גבוהה על תחזוקת באג (פינג-פונג בודק-מתכנת).

המידע מוביל לבעייה

1. האם יש לו את כל הקבצים שצריך (לוגים, צילומי מסך וכד')? המשך של סעיף 1.

2. את כל הפרטים הנכונים (מס' גרסה וכד').

3. יש את כל הפרטים הנחוצים ואין פרטים מיותרים.

הבאגים מכסים את האזורים שיש לגביהם סיכון

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

אם אין באגים בפיצ'רים חדשים או בעייתיים אולי הבדיקות לא יעילות.

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

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

הצעות להגדרת חומרה של באג: https://www.testerschoice.xyz/2008/02/severity.html 

לשיפור כל הסעיפים למעלה אפשר לקרוא כאן:

כתיבה מקצועית של דיווח על באג (testerschoice.xyz)

באגים רב-מימדיים

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

להלן סוגים של באגים רב מימדיים.

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

הבעייה שיש כשל שעשוי להיות חמור, מצב שאף אחד לא חשב עליו, שיכול להוביל לבעייה קריטית.

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

אם אין שינוי בסוג הנתונים שאנו מסנכרנים הסנכרון קצר, אם יש - ארוך ובזבזני במשאבים.

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

עד כאן הכל טוב.

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

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

הבנה מקיפה של המוצר

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

דוגמה אחרת: באג של יוזביליות שאינו ברור מאליו.

הבנה טכנית

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

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

הבנה מה מקור הבאג

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

סיבת הבאג

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

כולם אמרו, אז אמרו

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

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

שחזור מורכב

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

אסקייפ באגס

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

אחרי שיש לנו את הרשימה של האסקייפס, צריך לנתח ולהבין את ה-Root Cause ולוודא שזה לא יקרה שוב.

עוד מידע:

Escapes analysis and retrospective process (presentation) (testerschoice.pro)

שיפור תהליך הפיתוח והבדיקות - היכן היה אפשר למצוא את הבאג (testerschoice.xyz)

באגים שלא נובעים מטסטים

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

הערה כללית

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

הערכה של Test Cases

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

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

• האם הכיסוי טוב? כלומר כל הפיצ'רים של המערכת מול המפרט מכוסים.

• האם דברים שלא כתובים במפרט נבדקים?

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

• האם יש בדיקות שליליות?

• האם יש תיאור של הטסט (מה הוא בודק בעצם)? דבר פעוט זה חוסך הרבה זמן אח"כ. אם זה טסט כתוב עם צעדים (scripted), סביר שמישהו אחר יריץ אותו ולא תמיד ברור מה אמור להיבדק, אפילו אם השם של הטסט אינפורמטיבי. הייתי בישיבות ריוויו של טסטים שכותב הטסט לא זכר על מה הטסט.

• האם הטסט מחובר לדרישה? לטרייסביליות.

• השלבים והתוצאות הצפויות ברורים? האם כל בודק טכני שנמצא לפחות חודש בחברה יכול להריץ אותו?

• התוצאות הצפויות הן דטרמיניסטיות ומפורטות (ולא success)?

• קיימים קבצים מצורפים?

• ישנם תנאים מוקדמים מפורטים כשצריך?

• האם TD מעודכן לאחר הביקורות?

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

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

• האם זה מדמה התנהגות לקוח אמיתית?

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

ישיבה עם הבודקים

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

• הראה לי את העבודה הטובה ביותר שלך משבוע שעבר.

• הראה לי את הבאגים הכי מעניינים שלך.

• הראה לי את הטסט קייסס המעניינים ביותר שלך.

• מה בדקת? למה עשית את זה בצורה כזו? האם חשבת על זה?

סיכום

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

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

Cem Kaner, JD, PhDת Measuring the Effectiveness of Software Testersת STAR East 2003 http://www.testingeducation.org/a/mest.pdf 

Guru99 Software Testing Metrics: What is, Types & Example Software Testing Metrics: What is, Types & Example (guru99.com)

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

"By that experience Tukey and I discovered that what goes on in different people’s heads when they think they’re doing the same thing—something as simple as counting—is different for different people."

Feynman, Richard P.. "What Do You Care What Other People Think?": Further Adventures of a Curious Character (p. 59). W. W. Norton & Company. Kindle Edition. 

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

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

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

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

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

הנה כמה הבדלים שעולים על הדעת בין בודק התוכנה המקצועי לבין הלקוח (כאשר אני אומר "לקוח" אני חושב במיוחד על מישהו שמשתמש באפליקציות לא ככלי משמעותי במקצוע שלו, כיישום חשבונאי לרואה חשבון, אלא אנשים המשתמשים באפליקציות כחלק ממשימות היומיום או הבידור שלהם):

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

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

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

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


פתרונות?

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

Pairwise Testing AKA All Pairs Testing

כידוע לכל בודק מתחיל, יש יותר אפשרויות בדיקה מאשר זמן שמוקצה לבדיקות.
  
למשל יש לנו קטגוריה של מערכות הפעלה, ובקטוגוריה זו יש לנו שמונה מערכות שעלינו להקיף.
ובכל מערכת אנו בודקים את קטגוריית המשתמש שערך ראשון זהו המשתמש בעל הרשאות האדמין והערך השני הינו משתמש עם הרשאות מוגבלות, כלומר שתי אפשרויות.
ובקטגורית הדפדפנים יש לנו גם שמונה (אני כולל דפדפן וגרסה כערך אחד, אז יש לנו אקספלורר 9 כערך אחד, אקספלורר 10 כערך שני וכד').
כמה אפשרויות בדיקה יש לנו כאן? פשוט מכפילים: 8x2x8 = 128 אפשרויות.
  
כיוון שבפועל בד"כ יש יותר אפשרויות, וכיוון שבפועל בד"כ אין הזמן לבדוק את הכול מה עושים? מצמצמים.
  
לפי מה מצמצמים? כך עשינו עד כה:
סבירויות גבוהות יותר למשל אנו יודעים שלרוב המשתמשים היום יש מערכות הפעלה של Win7 אז חלק יחסי ובהתאמה גדול יותר של הבדיקות יתרכז במערכת הפעלה זו.
ניהול סיכונים - אנו יודעים שבמשתמש ב-WIn XP עלולות להיות יותר בעיות התקנה קריטיות במשתמש עם הרשאות מוגבלות אז נוודא שזה נבדק היטב.
מוודאים שכל ערך נבדק תחת כול קטגוריה, כולל ערכים שמשפיעים האחד על השני. למשל בדיקת קטגוריה דפדפן פתוח או סגור בודקים לא רק כשכל דפדפן פתוח וסגור אלא גם צירופים, למשל במקרה אחד: *IE פתוח אבל *CH סגור וכך גם ה-*FF.
  
זה לא רע ואני יכול לומר שבסה"כ כנראה שעלינו על רוב הבאגים. אבל תמיד הייתה לי הרגשה שזה לא מספיק טוב.
  
כאן נכנסת לתמונה מתודת ה-Pairwise Testing.
  
לפי מחקרים**, ולא פחות לפי האינטואיציה, רוב הבאגים נמצאים בערכים יחידים, כמו שהתקנה נכשלת ב-Win 8. חשוב לציין שייתכן שזה קורה גם בשאר מערכות ההפעלה או בחלק מהן, אבל עדיין מדובר בערך בודד ולא בצירוף של ערך עם ערך אחר בקטגוריה אחרת. לפי המחקר הנ"ל בין 30% ל-70% מהבאגים מתגלים כאן. אגב את זה ואת שאר ההנחות כאן אפשר לבדוק בקלות במערכת ניטור הבאגים שלכם.
  
החלק הגדול השני של הבאגים מתגלה בצירוף של שני ערכים מקטגוריות שונות. למשל באג שקורה בכרום במקרה שהרשאות המשתמש הן מוגבלות.
  
חלק קטן הרבה יותר יקרה בצירוף של שלוש קטגוריות, למשל באג שקורה רק ב-Win XP, רק במשתמש מוגבל ורק בכרום. אני מניח שצירוף כזה עשוי להיות נדיר גם אצל המשתמשים, אבל לא לסמוך על זה.
  
ויש אחוזים בודדים של באגים שיקרו בצירוף של ארבע קטגוריות ומעלה.
  
איך זה מתקשר לאפשרות המוגבלת שלנו לבדוק בצורה איכותית כמויות רבות של ערכים? התשובה היא שאנו פשוט נבדוק את כל המקרים הבודדים, ואת כל הצירופים של שני ערכים קיימים. תוך כדי כך נבדוק ממילא את כל הקטגוריות יחד (לפחות במקרה שלי) אבל לא את כל צירופי הערכים.
  
הינה דוגמא***:
יש לנו שלש קטגוריות עם שני ערכים בכל אחת:

X = A,B

Y = C,D

Z = E,F

  
אלו כל האפשרויות שלנו:

אפשר לראות שאת הזוג A ו-E בודקים בטסט 1 (T1), את A ו-D בטסט 4, ואת D ו-E בטסט 6.
כלומר שלשת הצירופים הזוגיים של טסט 2 נבדקים ולכן ניתן להסיר אותו.
  
לאחר שנעשה כך על כל הצירופים, נוכל להגיע למצב הבא:

ובזהירות - שלא נוציא שורות שהסתמכנו עליהן.
לא רע בכלל.

חסרונות:
1. עצוב שמראש יודעים שאנו מוותרים על אחוז מסוים של באגים. מצד שני, בכל מקרה אנו מוותרים עליהם.
2. בהסתמך רק על המתודה שלעיל אנו עלולים להפסיד קומבינציות חשובות. לכן חשוב מאוד שבודק מיומן יבחן את התוצאות, כלומר את הצירופים החשובים, ויוודא ש:
- אנו בודקים יותר את הסבירויות הגבוהות יותר.
- אנו בודקים מקומות מסוכנים יותר.
3. חשוב לבחור את הפרמטרים הנכונים. למשל, אני יכול להחליט שאני לא בונה קטגוריה שתכיל כל מערכות ההפעלה אלא מספיקה לי קטגוריה של 32 מול 64 ביט. לפי המוצר שלי, ייתכן שזו חלוקה נכונה, אבל ייתכן שחשובה לי הרבה יותר קטגוריה של מערכות הפעלה שתכיל את כל האפשרויות של הביטים בתוכה.

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

* FF - Firefox

IE = Internet Explorer

CH = Chrome

** למשל הגעתי לכאן דרך מאמר במגזין "חושבים בדיקות".
  
*** מכאן

• Mar 18, 2016

שיפור תהליך הפיתוח והבדיקות - היכן היה אפשר למצוא את הבאג

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

אבל לא פחות חשוב לדעת אילו באגים "ברחו" גם בנקודות אחרות של התהליך:

• מסמכי שיווק;
• מסמכי מהנדס מערכת;
• מסמכי פיתוח;
• Unit tests;
• Private Integration;
• Integration Tests;
• וכמובן שלבי הבדיקה:
  Sanity;
  פרוגרסיות;
  רגרסיות;
  ועוד.

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

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

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

ההמשך הוא בהתאם לתוצאות: אם למשל הבעייה ב-Unit tests יש לבצע הערכה:
אילו איזורים חסרים? האם צריך לעדכן את כל הבדיקות או יש פערים מסויימים? האם אפשר לוותר על חלק מהבדיקות כי אין יותר סיכון בקוד הנ"ל? במקרה זה כדאי שהבודקים יעשו review על בדיקות ה-unit test ובכלל יעבדו צמוד עם הפיתוח.
אם אלו מסמכי מהנדס המערכת או השיווק: האם יש review מסודרים? האם אנשים באים מוכנים? אולי יש צורך לעזור לאנשים למצוא באגים במסמכים (זה לא קל)?
וכן הלאה.

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

שיפור הבדיקות 4: הפקת לקחים - Lesson Learn

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

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

----

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

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

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


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

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

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

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

שיפור הבדיקות 3: סדרי עדיפויות

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

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

מה כן עושים?

1. קודם כל, אוספים את הבעיות. פשוט לבוא עם רשימה שיש לך כמנהל ממה שהספקת להכיר, לשבת עם אנשי הבדיקות, אנשי הפיתוח, מנהלי הפרויקטים, מהנדסי המערכת, ולשמוע מכולם מה מפריע להם הכי הרבה בתהליך הבדיקות.
2. מחלקים לנושאים עיקריים ותתי נושאים.
3. מחלקים חשיבויות לנושאים שרשמנו. אפשר להעזר בטבלא הבאה, אבל אפשר בדרכים שונות:
   חשוב חשוב פחות
   ___________דחוף
   ___________דחוף פחות
4. לוקחים את שלושת הנקודות הבעייתיות יותר ומטפלים בהן קודם. הסדר הוא:
   נקודות שהן חשובות ודחופות קודם, אח"כ חשובות פחות אך דחופות, חשובות ודחופות פחות, ולבסוף חשובות פחות ודחופות פחות.
   יש לשמור "צילום" של המצב בכדי לחזור אליו לאחר זמן ולראות אם אכן קטנו מספר הבעיות וחומרתן.
5. לגבי הנקודות שמתחילים איתן, לפרק לתת-בעיות.
6. לכל תת-בעייה לתת פתרונות ברורים, להבין מהו קריטריון ההצלחה של כל קריטריון, אלו נקודות יש לממש בכדי להגיע לפתרון הבעייה, אחראי וזמן התהליך.
7. להניע ולנהל את שלשת התהליכים הנבחרים.
8. נפתרו? ממשיכים עם שלשת הבאים.

דוגמא רק בכדי לסבר את האוזן:

• בעייה אחת היא אי-עמידה בלוחות זמנים. זו בעייה חמורה שיש לטפל בה בדחיפות (4 נק').
• פחות חשוב לגשת להשלמת השכלה מסויימת כי זה בעיקר העשרה, אבל זה דחוף כי כרגע יש הזדמנות שאולי לא תחזור במהרה (3 נק').
• בעייה אחרת היא חוסר מקצועיות טכנית ספציפית של מספר מועט מאוד של בודקים, אך הם יכולים לעסוק בדברים שהם כן מכירים. הדחיפות היא לא גבוהה, החשיבות - כן (2 נק').
• או למשל שחלק מציוד המעבדה ישן, אך עדיין אמין ומבצע את המצופה ממנו - לא דחוף ולא חשוב כרגע, יש לשם בצד ולטפל בהמשך (1 נק').

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

מצ"ב דוגמא לקובץ אקסל המכיל טבלה של פירוק בעייה לגורמים עם דוגמא.

שיפור הבדיקות 2: ישיבת שיפורים

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

1. מהנדס מערכת (של הבדיקות או בכלל).
2. מנהל תחום הבדיקות.
3. נציגי צוותי הבדיקה (הזדמנות מצויינת לתת לבודקים מן השורה אחריות נוספת).
4. אפשר להביא "אורחים" יעודיים - אם מדובר במשהו שקשור לפיתוח אפשר לזמן נציג שלהם וכד'.

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

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

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


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

שיפור הבדיקות 1: סיכום מאמר

סיכום המאמר שיפור תהליך הבדיקות אינו מחייב.
אני לא חושב שזהו מאמר מבריק, והוא חוזר על אותן הדוגמאות שוב ושוב, מה שמראה שהוא לא יושם כנראה באופן מלא ע"י מי שכתב אותו.
יחד עם זאת, שווה לקרוא בכדי לקבל רעיונות.
מה שבכחול - הערות שלי.
Escape - הגדרה:
escape מוגדר כבאג שעבר / לא התגלה בחדר הבדיקות אלא אצל הלקוח. כידוע באג שמתגלה בשלב זה מחירו הוא היקר ביותר. לשם כך יש לנתח את ה-escape בכדי להבין איך זה קרה, למנוע הישנות המקרה בעתיד, ולגרום לגילוי עתידי כמה שיותר מוקדם בתהליך הפיתוח.

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

התהליך מתמקד בבעיות בעלות חומרה רבה, שכילות ויקרות. מטרת אנליזת ה-escape היא:

• הפרדת ה-escape לתוך קטגוריות בכדי להקל על אנליזת העומק.
• הרצת סטאטיסטיקות על הקטגוריות הנ"ל.
• על סמך הסטאטיסטיקות הנ"ל לזהות וליישם שינויים בתהליכים.
• לזהות וליישם שינויי low level על סמך אנליזה של מקרי escape.
• לעקוב ולהציג את תוצאות השיפורים.

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

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

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

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

• Process step, כלומר היכן שהבאג היה אמור להתגלות:
  בשלבי הפיתוח (מה-review של שלב המרקטינג, של מסמכי הפיתוח, דרך קוד review, דרך ה-Unit test ועוד).
  בשלבי הבדיקות.
• באילו קומפוננטות התגלו הבעיות.
• ה-impact של הבעיות במחינת הלקוח (קריסה, בעיות של מידע, עומס, יוזביליות וכו').
• גרסאות הקוד שבהן היו הבעיות.
• פלאטפורמה.
• חומרה.
• גרסה בה התגלו הבעיות.

לאחר בחירת הקטגוריות יש להריץ סטאטיסטיקות עליהן.

אנליזה - כלי לניטור
יש להשתמש בכלי לניטור ותיעוד האנליזה, כמו lotus notes ואני מוסיף: אקסל כמובן.

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

אנליזה - שינויי היי-לבל בתהליך
על קבוצת אנליזת ה-escape להיפגש בכל פעם שיש אנליזה (כאמור יכול להיות פעם ברבעון) בכדי לדסקס את התוצאות. יש לזהות מגמות ולערוך סיעור מוחות על הממצאים ולמצוא שיפורים בהיי-לבל של תהליכי הפיתוח. לאחר מכן על הקבוצה לתת המלצות פורמליות לשיפורים ולערוך תוכניות לצעדי השיפור. יש לערוך ישיבות קבועות ולעקוב אחרי השינויים. בקיצור, יש לנהל את השינויים כמו ניהול של כל פרוייקט אחר. דוגמא לשינוי היא רכישה של חומרה זהה לזו של הלקוח.
אנליזה - שינויי ה-low level בתהליך
אם עובדים ברמת חברה עם כמה קבוצות, יש לבחור לקבוצת האנליזה נציג מכל קבוצה (קבוצות פיתוח, קבוצות בדיקה, הנדסת מוצר, תשתיות, מהנדס מערכת ועוד). יש להקצות escape לנציג המתאים, למשל escape שקוטלג לתהליך ה-Unit Test צריך להינתן למפתח שעורך UT להמשך האנליזה. על כל נציג קבוצה לקחת על עצמו את ה-escapes מהתחום שלו ולחזור עם הצעות שיפור. אם זה הבדיקות אז עליהם לחזור עם פעולות לשיפור שימנע את הישנות הבעייה ומקרים דומים. על תוכניות הפעולה להיות מלאות, מאושרות ואז מיושמות ויש לעקוב אחרי זה. יש להקצות תוכנית פעולה לכל escape. יש להדגיש שזה לא נועד לפתור באג ספציפי אלא לשפר תהליך. תוכנית השיפורים חייבת להיות כזו לתוריד את האפשרות לבריחת באג מאותו סוג. למשל: הוספת test case. יש לעודד יצירתיות.

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

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

בתמונה 2 ניתן לראות את טאב האנליזה של הפיתוח. יש קטגוריות שונות לקלסיפיקציה של הבאג. בדוגמא הספציפית הבאג "ברח" בשלב של ה-Design Review. בכדי לתקן זאת נוספה פרוצדורה חדשה. ייתכנות התפיסה (Capture Probability) נועדה להעריך את האפקטיביות של הפתרון. האחוז אמור לענות על השאלה: מהי הסבירות שבאג זה היה מתגלה אם היינו מיישמים את הפתרון המוצע כבר אז?
יש גם שדה לקביעת תאריך הסיום.

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

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

מדידות להנעת תהליכים
מדידת סה"כ בתוך כל קטגוריה שקטלגנו במידע ויצירת תרשים שיביא את השינויים לידי ביטוי. בהמשך יש כמה דוגמאות.
תמונה 4 מראה את האחוז מסך כל ה-escapes מכל קומפוננטה של קוד. ברור מצפייה בתרשים שארבע קומפוננטות מרכיבות כ-50% מהבעיות. זה יכול לעזור לקבוצה לגלות שיש לנקוט בצעדים על מנת לשפר את הקומפוננטות הנ"ל.

תמונה 5 היא לפי השפעות על הלקוח כמו קריסה וכד'. שוב יש לפעול לפי סדר של כמותי הבעיות הרבות יותר תחילה בשילוב עם החומרה של הבעיות.

מדידת יעילות של אנליזת ה-escape
מידע מדוייק ודיווח מתמשך הכרחיים למדידת השיפורים.

TFVUD = Total Field Valid Unique Defects
כלומר סך כל הבאגים הואלידיים והסגורים שהתגלו אצל הלקוח.

PDD = Post Development Defect
באגים שהתגלו לאחר הפיתוח אבל לפני השליחה ללקוח.

KLOG = שורות של קוד באלפים.

א. TFVOD לחלק ב-KLOG קיימים וששונו.
הערך הזה אמור לקטון עם הזמן בהשוואה לגרסה אחרת באותה נקודה בתהליך.
המטרה במדידה היא לראות ירידה במספר הבעיות הואלידיות שהתגלו ע"י הלקוח יחסית למספר שורות הקוד.

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

ג. ייתכנות התפיסה
למדידה זו יש להשתמש בשדה בעל שם זה הקיים בבסיס הנתונים בטפסי ה-escape. זה יעריך את יעילות השינוי אם נמנע escape של הסוגים הנדונים. אמנם זו רק הערכה, אבל היא יכולה לשמש בסיס טוב להצגת האפקטיביות.
ניתן לסכום את ייתכנות התפיסה ומציאת ממוצע בכדי להבין את היעילות הכללית של קומפוננטה מסויימת, השפעה אצל לקוח וכד'.
כתוצאה ניתן להציג הערכה של ירידה שלבעיות בשטח.
ראו תמונה 6. לקומפוננטה B ייתכנות התפיסה של הפיתוח או הערכת האפקטיביות היא 35%. ייתכנות התפיסה של הבדיקות ל-B היא 30%. כלומר אם היו לפיתוח 100 באגים הם ימצאו 35 מתוכם. זה יותיר 65 באגים לבדיקות. אם הבדיקות ייתפסו 30% מהבאגים, כלומר 19.5, זה ס"כ הבאגים שיתגלו יהיה 35 + 19.5 שהם 55 APARים או 55% מהמאה המקוריים. 55% אלו נקראים בשם "יעילות משותפת". הנוסחה של זה נראית כך:
D = ייתכנות התפיסה של הפיתוח
T = ייתכנות התפיסה של הבדיקות
(D+(1-D)(T
המקרה שלנו:
0.35+(1-0.35)(0.30)
דוגמא זו מבוססת על קומפוננטות, אך יכולה לחול על מאפיינים אחרים גם כן - ראו תמונה 7.

הצעד האחרון הוא לשקף את הכמות שבה ניתן להוריד את הבאגים אצל הלקוח. זה נעשה ע"י סכימה ועריכת ממוצעים של ערכי היעילות משותפת. תחילה יש לבחור קבוצה של escapes שיהיו קבוצת הפוקוס של היעילות משותפת. בדוגמא הזו קבוצת הפוקוס תכלול 76 escapes. אם ערך היעילות המשותפת של 76 באגים אלה תסוכם ויעשו לה ממוצעים לדוגמא מציור 7, התוצאה תהיה 52.5% יעילות ל-76 באגים, כלומר 40 escapes שלא יגיעו ללקוח. כלומר אם היו 250 escape בשנה 16% ימנעו.

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