יום שלישי, 29 בדצמבר 2020

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

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


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

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

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

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

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

- האם הבאגים אפקטיביים? למשל אם אין הרבה דיווחים על באגים שבפועל מצביעים על תפקוד נורמלי של המערכת (ה-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)







יום שישי, 6 בנובמבר 2020

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

הקדמה

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

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

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

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

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

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

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

 

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

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

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

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

התהליך

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

כך ראיתי את התהליך:

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

 

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

השאלות

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

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

המשתתפים

23 מתוך 30 בעלי הסכימו להשתתף.

הראיונות

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

כל מי שהסכים שיתף אותי במה שמפריע לו.

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

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

Photo by mentatdgt from Pexels


מה היו חלק מהנושאים שעליהם דובר

  • ניהול אנשים;
  • פיתוח אישי;
  • נושאים כלליים (כמו שיתוף-פעילה עם קבוצות אחרות;
  • גיבוש הקבוצה;
  • העברת יידע לחדשים וגם לאלה שלא.

ניתוח הממצאים

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

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

  • חלוקת הנאמר לפי נושאים שלא נקבעו מראש;
  • ציון כמות אנשים שהעלו את הנושא;
  • תמצות של מה שהם אמרו.

התוצאות

את התוצאות סידרתי לפי האחוז של האנשים שהעלו אותם.

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

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

 

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

ההצגה

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

קבלה והמשך

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

הדיון היה פורה, ואף קבענו וישבנו בישיבות המשך.

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

 

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

מסקנה אחרת

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

יום שני, 11 במאי 2020

Test Management Tools battle in Jira: SynapseRT VS Xray - קרב מנהלי הבדיקות בג'ירה

סיפרתי על ההעברת הבאגים מה-Quality Center לג'ירה בעבר. אבל מה עם הטסטים?

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

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

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

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





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