כשאנחנו מדברים על איכות הבדיקות אנחנו מכוונים לשיפור המוצר, להתייעלות, לקיצור זמני הגרסאות ולחדשנות ללא ירידה באיכות המוצר. כיצד נבין שאנחנו כחברה בדרך הנכונה? ואם לא איך נדע מה חסר ואיך אפשר לשפר?
ברצוני להציע כאן דרך לניטור שכוללת לא רק מדדים אלא גם הערכה איכותית של יעילות הבדיקות. אבל קודם נעמוד על כמה סוגיות בדרך.
למה בעצם לנטר את היעילות של הבדיקות?
בין אם אנחנו מנהלי בדיקות שרק עכשיו נכנסנו לחברה חדשה או לחילופין מנהלים עם ותק במקום מסוים, חשוב לנו להעריך את איכות הבדיקות בחברה, או במילים אחרות לענות על השאלה: האם הבדיקות יעילות? ניתן לחלק את השאלה למספר תתי שאלות , למשל:
- האם הבדיקות אכן מוצאות את הבעיות העיקריות של המוצר? למשל אל מול מה שנמצא ע"י לקוחות.
- האם הבודקים מכירים את המוצר מכל מיני בחינות - טכנית, מוצרית, שינויים ועוד? למשל כמות הריג'קטים.
- האם הבאגים אפקטיביים? למשל אם אין הרבה דיווחים על באגים שבפועל מצביעים על תפקוד נורמלי של המערכת (ה-Works As Designed) כנראה שהם אפקטיביים בממד זה.
- האם סבבי הבדיקות אורכים פרקי זמן סביר?
בכדי לענות על שאלות אלו אנו עשוים להשתמש במדדים והערכות, כלומר אנו מנטרים את מצב העניינים.
לפני שקופצים למדדים והערכות, בואו קודם נדון בשאלה: למה אנחנו רוצים להעריך או לנטר את היעילות של הבדיקות?
אנחנו מנטרים את היעילות של הבדיקות כדי לדעת איפה אנחנו עומדים לעומת החזון של איפה אנחנו רוצים להיות. ולמה אנחנו רוצים לדעת את כל זאת? המטרה שבשלה אנחנו רוצים להעריך את היעילות שלנו היא כדי לשפר את איכות הבדיקות.
ניטור זה לא הכל!
חשוב שיהיו מדדים כמותיים והערכות איכותיות בשביל לדעת מהי איכות הבדיקות, את מצב הגרסה והמוצר, וגם לבדוק שאנחנו לא מפספסים כלום. אבל בואו נשים את כל זה בצד רגע. כדאי בראש ובראשונה פשוט להסתכל על תהליך הבדיקות ולחשוב אם יש נושאים גדולים לשיפור שזועקים לשמיים. למשל:
מה ההיקף של הבדיקות? האם כל מה שצריך להיבדק נבדק (ולהיפך)?
האם אנו משתמשים בכל הכלים הנדרשים למצוא באגים (למשל סימולטורים)?
מה המצב של הפיתוח ככלל? למשל נהוג לעשות קוד ריוויו?
אוטומציה - קיימת? בכל הרמות? אפקטיבית?
++ בעצם כל מה שקשור בניהול נכון של הפיתוח כולל הבדיקות.
אם למשל יש חלקים במוצר שלא נבדקים בכלל. אולי אפשר לעשות קצת בדיקות בחלקים אלה (אקספלורטורי כמובן) ולוודא שהם עובדים כמצופה. אם הם לא - בום! הנה סיבה למה הלקוחות שלנו עושים QA במקומנו. ולא היינו צריכים לנטר דבר בשביל להבין את זה!
מדדים
מהו מדד? לפי וויקי:
"מדד הוא מספר המייצג את רמתו של מאפיין מסוים, כדרך להשוות בין רמות שונות של מאפיין זה בזמנים שונים, במקומות שונים או במקרים שונים.
גודלו האבסולוטי של מדד אינו חייב להיות בעל משמעות (אם כי יכול שיהיה כן), אולם, היחס בין שני מספרי מדד שונים מצביע על השינוי ברמת המאפיין אותו המדד מייצג.
מדדים מספקים מידע לחוקרים ולמקבלי החלטות, ולעיתים יש להם גם שימוש מעשי יומיומי."
 |
| Photo by Ishant Mishra on Unsplash |
המדידות, הן כלי עוצמתי שאכן מגלה מימד מסוים וחשוב. כדאי שיהיו מדדים ויעדים למדדים אלה אשר מוסכמים בחברה, וחשוב לעקוב אחריהם כיוון שהם נותנים מידע מדויק שממנו אפשר להסיק על מצבם של תהליכים או פריטים מסוימים שחשובים לנו. ההחלטה לגבי המדדים היא החלטה אסטרטגית כי היא צריכה לשרת את מטרות החברה. זהו כלי מהיר לניטור שינויים, ובדרך-כלל אחרי שהקמנו אותו הוא ממשיך לרוץ עם תחזוקה שאינה יומיומית.
דוגמה למדד הוא מספר הבאגים שהגיעו מהשטח (אסקייפס), ואם הם עוברים יעד שנקבע מראש, נניח 7% מול הבאגים בגרסה שנמצאו, כדאי להבין איך זה קרה (למשל ראו כאן: https://www.testerschoice.pro/single-post/Escapesanalysisandretrospective ). כמובן שזה תהליך שלא נועד כדי למצוא "אשמים" אלא לעזור לעצמנו להשתפר. אם המספר הגבוה של האסקייפס נובע מכך שחסרים לנו בבדיקה מכשירי מובייל נפוצים בשטח - בואו נוודא שאנחנו פותרים את זה בין אם ברכישת מכשירים, קראוד טסטינג ועוד.
אולם מדדים כמותיים, טובים וזמינים ככל שיהיו, אינם אלא תצוגה אלגנטית של מספרים ולא תמיד יכולים לתת תמונה מלאה ולהסביר את הנתונים או לרמוז על סיבתם, ובוודאי לא לענות על השאלה 'איך לפתור את הנושאים שעלו?'. על מנת להשלים את התמונה אנו זקוקים למפתח להצלחה - למדדים איכותיים.
היה צוות בדיקות בחברה שעבדתי בה שהיה להם אחוז ריג'קטים גבוה. הסיבה הייתה שראש הצוות נהג לעודד את הצוות שלו לפתוח את כל הבאגים מהשטח גם לפני אימות. כלומר זה לא אמר כלום על יכולות הצוות.
הריצה למדדים לפעמים כל-כך טבועה בנו שאנו פשוט עושים אותה בצורה אוטומטית מבלי לחשוב על מה בעצם המדידות מצביעות; לעתים, גם אם יש הבנה, לא תמיד מגיעים לשלב הבא שהוא מה עושים עם הנתונים שקיבלנו. כדאי לשבת ולנתח אותם.
הערכה איכותית
בין אם אתם מודדים ובין אם לא, כמנהלים כדאי שנהיה קרובים מאוד למה שקורה יום-יום בתהליך הבדיקות. לשבת עם הבודקים בזמן הבדיקות, לבדוק בעצמנו ולבדוק את התוצרים עצמם. מנהלים בעלי ניסיון וידע ידעו את מצב תהליכי הבדיקות לפעמים בצורה טובה יותר ממדדים, או רק ממדדים. זוהי הערכה איכותית שפירושה כאן ממש לעבור על התוצרים של הבדיקות - למשל באגים וטסטים - להעריך את האיכות של כל אחד מהם, ואפילו לתקן בו במקום את התוצר ו/או לשוחח עם הצד הרלוונטי ולעדכן אותו בקשר לטעות בדיווח או תהליך שפוספס. לא רק לראות שיש באגים שעוברים וחוזרים בין מפתח לבודק, אלא להבין מרמת הבאגים עצמם מדוע זה קרה. מדדים כמותיים מראים את התמונה במבט-על, לעומת זאת הערכה איכותית ממש נכנסת לעומק של התופעות. חשוב שנשתמש בשני הסוגים, ואפשר לומר שהם משלימים זה-את-זה.
לא כל באג מספר סיפור, ואם באג חזר למפתח כיוון שבאופן נדיר הוא פספס צעד בשחזור אין צורך במעקב אקטיבי. אבל אם אני רואה הרבה כאלה, כדאי לעשות חשיבה משותפת עם המפתח ולהבין על מה הדבר מצביע ואיך ניתן לשפר.
הערכה איכותית מזמנת בנוסף שיח אחר בין הפיתוח לבדיקות, שיח מקצועי, משותף, בעל עומק, הגורם לפיתוח מקצועיות ויכול לקדם איכות המוצר לרמה חדשה ברוח האג'ייל.
שילוב ניטור כמותי ואיכותי
ייתכן וממעבר יומי על התוצרים לא נדע את אחוז הריג'קטים, וממדים לא נדע למה המספרים עלו. אבל אם אנו עוברים על הבאגים באופן קבוע ו"חותמים" על איכות הבאגים ייתכן שלא יהיו הרבה ריג'קטים. ולכן כדאי להשלים את המדדים הכמותיים עם הערכה איכותית.
כשאנו מודדים את כמות ה-reopen באופן קבוע וכמות זו עולה, זו נורת אזהרה. זה יכול לומר הרבה: אולי הבאגים ככלל לא ברורים, הרבה פעמים חסרים נתונים, המפתחים לא בודקים את התיקונים שלהם, ועוד. כשאנו מנטרים רק בצורה איכותית אנו בוודאי נראה דברים כגון אלה, אבל אולי לא נבין שיש בעייה כללית יותר, בעיקר עם העלייה במקרים אלו היא הדרגתית. לעומת זאת, יכולים להיות מקרים שאין עליה וזאת כיוון שהתמעטו מקרים כאלה, אבל בגלל מפתח או בודק חדשים שעושים הרבה טעויות המדד לא השתנה. גם את זאת נבין בניטור איכותי.
אני רוצה להציע מספר כלי הערכות איכותיות. הראשון הוא יעילות הבאגים.
יעילות הבאגים
הבאג הוא כלי בסיסי של הבודק שנועד להצביע על בעיות במוצר. אם הבאגים לא יכולים להוביל לפעילות של תיקון - יהיה אפשר לראות את זה במוצר. כשאת מסתכלת על הבאגים את יכולה להעריך יפה את האפקטיביות של הבדיקות. האם הבאגים אומרים משהו (ברורים)? אפשר להיעזר בהם כדי לפתור את הבעייה (מידע כתוב, לוגים)? האם הם מגלים בעיות מורכבות יותר או רק מגרדים את השטח? האם הבדיקות מתנהלות בצורה מקצועית? האם הידע הטכני ואחר קיים?
כדי לעזור לכם להעריך את הבאגים, להלן רשימת תכונות של באגים איכותים שאם הם חסרים בדיווחי הבאגים אצלכם צריך להבין מדוע.
לדעתי עוד לא נוצר סיווג כזה של באגים. בדרך-כלל הסיווג מסתכם בחומרה-תכיפות או צפי (או חוסר), סיווג צורני של הבאגים (נניח אם התיאור ברור) וחלוקה של באגים לפי קטגוריה של פיצ'רים במוצר.
לגבי היקף המעבר על הבאגים והתזמון, אפשר לעבור על כל הבאגים, הבאגים של הגרסה הנוכחית, כל יום על הבאגים של היום הקודם. בנוסף כדאי לפלטר באגים שנפתחו מחדש, שקיבלו ריג'קט, שנסגרו. שלבים מעניינים במחזור החיים של הבאג.
אז מה אנחנו מעריכים?
סיווגי דיווחי באגים לפי איכות הבאג
אני מכניס כאן את מה שאנחנו כבר עושים ממילא כמו וידוא שהמידע ברור וממשיך בהדרגה למקומות נוספים.
המידע ברור
האם הבאג כתוב בצורה ברורה? אם לא מצבנו לא טוב מכמה סיבות:
זו יכולת בסיסית אצל בודקים, אם היא לא באה לידי ביטוי צריך לבדוק למה.
היא יכולה להצביע על השקעה גבוהה על תחזוקת באג (פינג-פונג בודק-מתכנת).
המידע מוביל לבעייה
האם יש לו את כל הקבצים שצריך (לוגים, צילומי מסך וכד')? המשך של סעיף 1.
את כל הפרטים הנכונים (מס' גרסה וכד').
יש את כל הפרטים הנחוצים ואין פרטים מיותרים.
הבאגים מכסים את האזורים שיש לגביהם סיכון
האם הבאגים באים מכל האזורים במערכת? כאן בהחלט אפשר להשתמש בדוח טרייסביליות אבל גם ב-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)
אין תגובות:
הוסף רשומת תגובה