מדידות הן לא רק עניין אסתטי או נתוני טרוייה מעניינים ככל שיהיו. מדידות נועדו בסופו של דבר לשפר את ביצועי המערכת או להתריע על בעיות בזמן אמת. חשוב לזכור זאת גם בקביעת המדדים וגם בהצגתם.
יש למדוד באופן קבוע לאורך חיי המייזם.
יתר על כן, בשעה שאת מציגה את הנתונים עלייך להיות מוכנה עם המידע הבא:
א. מדוע יש שינויים אל מול המצב שנקבע בתחילה או כל דבר חריג אחר.
ב. מה את מתכוונת לעשות בכדי להחזיר את המצב לנורמלי.
בלי תשובות אין טעם להציג את התמונה (אלא אם זה נקבע מראש כסיעור מוחות).
שוב כרגע אני נותן את "מה" ובקושי אתייחס אל "איך". וכמובן כל אחד יכול לקחת אילו מדידות שהוא רוצה.
אלו המדדים שאחריהם לדעתי חשוב לעקוב בקשר לבדיקות:
1. כיסוי הדרישות מול test case.
כמה דרישות מכוסות ב-test cases, וכמה לא, כמה test cases לדרישה (1 - לא הגיוני, גם 100 לא).
2. כיסוי test case מול הרצות.
במדידה #1 לעיל הזכרתי דרישות מול מסמכים. מדידה זו, #2, היא של מסמכים מול ההרצות בפועל.
3. מצב לוח הזמנים:
המצב של הלו"ז נכון לכרגע אל מול הלו"ז שנקבע (אם זה בגאנט, יש לשמור baseline כשהתכולה פחות או יותר סגורה ומקובלת על כולם' אפשר בנוסף גם של גאנט מוקדם יותר).
טיפ: על כל תזוזה יש לכתוב note בגאנט או בכל מקום אחר כי מרוב אקשין אפשר לשכוח אח"כ מדוע עוכבנו.
4. מדידת זמן בדיקה בפועל אל מול ההערכה.
כך נדע אם טעינו בהערכה ונוכל ללמוד להבא.
בנוסף, נדע מחיר ריאלי של עבודה.
תוספת לסעיף 4 בעקבות קריאת המאמר למטה:
אפשר לבנות את הגראף כך:
קו של תכנון מספר ה-TC פר יום / שבוע
TC שנבדקו בפועל
TC שעברו.
אם התכנון הוא על כמה TC יעברו, נניח 50, ואמנם בדקנו אפילו 55 אבל רק 45 עברו - אנו בבעייה.
5. התקדמות בבדיקות.
פרוגרסיות ברמת test case מתוכנן מול מצב בפועל
רגרסיות ברמת test case מתוכנן מול מצב בפועל
כנ"ל לגבי sanity, ATP ומה שלא יהיה שמתוכנן.
6. מדידות של דיווחי באגים.
סטאטוס: פתוח, סגור וכד'.
חומרה: קריטי, מינורי וכד' (מומלץ לשלב עם הסטאטוס).
מספר הבאגים הקיים אל מול התכנון של צפי כמות הבאגים.
7. מספר באגים אל מול test case.
יעילות ה-test case.
בטווח הארוך אולי אפשר לוותר על בדיקות מסויימות או לקצר אותו, אולי לשפר אותו.
8. מצב הדרישות.
כמה נבדקו, כמה לא, מצב באגים.
חשוב מאוד אם אנו נרצה לפתע לשחרר גרסה בדוקה חלקית נניח להמשך פיתוח אחר או לבדיקות פרוייקטליות.
9. בשלות / התכנסות הגרסה.
גרף באגים פתוחים מול סגורים (שני קווים לאורך הזמן).
אמור להתחיל עם 0 סגורים והרבה פתוחים, הסגורים יעלו הפתוחים יצטמצמו, עד ששני הקווים יפגשו, ולבסוף מעט פתוחים הרבה סגורים.
אפשר לציין בציר ה-X את תאריכי קבלת ה-buildים כדי לראות את השפעה שלהם מול קצב פתיחת הבאגים.
גם בודק את יעילות הבדיקות או ניהול גרסה: הרבה באגים שנפתחים בשלב מתקדם: האם הייתה תכולה חדשה או הבודקים לא מצאו באגים משום מה בהתחלה?
10. מספר הבאגים אל מול מספר דיווחי הבעיות מהשטח + באגים שהיו קיימים בגרסאות קודמות.
יעילות של בודקים.
11. יעילות שערים.
כמה תוכננו וכמה היו בפועל. רוצה לומר בעצם כמה בילדים מתוכנן מול קיים. אם היו יותר - מדוע?
כמה שערים עברו באיזה סטאטוס. מודד את איכות הדליברי לבדיקות.
12. זמן אי-עבודה.
הרבה פעמים העבודה נעצרת בגלל חוסר תמיכה, מעבדות לא כשירות, חוסר דרישות ועוד. יש לכמת ואח"כ להתחיל למצוא פתרונות מהקריטי לקל.
13. כמות ה-rejected bugs.
לא "עליהום" אלא להבין למה. אם בגלל טעויות של בודקים - לשפר להם את הידע הטכני והקשור לבדיקות. אולי הדרישות אינן טובות דיין.
14. באגים פר פאזה של חיי מוצר.
למשל כמה באגים על דרישות, דוקומנטציה וכד'.
15. באגים לפי ההשפעה שלהם.
פונקציונלי, התקנה ועוד.
16. באגים לפי אפליקציה / שרת.
עוד חומר אפשר למצוא כאן (תודה לדנית):
S. H. Kan, J. Parrish, and D. Manlove, In-process metrics for software testing
יש למדוד באופן קבוע לאורך חיי המייזם.
יתר על כן, בשעה שאת מציגה את הנתונים עלייך להיות מוכנה עם המידע הבא:
א. מדוע יש שינויים אל מול המצב שנקבע בתחילה או כל דבר חריג אחר.
ב. מה את מתכוונת לעשות בכדי להחזיר את המצב לנורמלי.
בלי תשובות אין טעם להציג את התמונה (אלא אם זה נקבע מראש כסיעור מוחות).
שוב כרגע אני נותן את "מה" ובקושי אתייחס אל "איך". וכמובן כל אחד יכול לקחת אילו מדידות שהוא רוצה.
אלו המדדים שאחריהם לדעתי חשוב לעקוב בקשר לבדיקות:
1. כיסוי הדרישות מול test case.
כמה דרישות מכוסות ב-test cases, וכמה לא, כמה test cases לדרישה (1 - לא הגיוני, גם 100 לא).
2. כיסוי test case מול הרצות.
במדידה #1 לעיל הזכרתי דרישות מול מסמכים. מדידה זו, #2, היא של מסמכים מול ההרצות בפועל.
3. מצב לוח הזמנים:
המצב של הלו"ז נכון לכרגע אל מול הלו"ז שנקבע (אם זה בגאנט, יש לשמור baseline כשהתכולה פחות או יותר סגורה ומקובלת על כולם' אפשר בנוסף גם של גאנט מוקדם יותר).
טיפ: על כל תזוזה יש לכתוב note בגאנט או בכל מקום אחר כי מרוב אקשין אפשר לשכוח אח"כ מדוע עוכבנו.
4. מדידת זמן בדיקה בפועל אל מול ההערכה.
כך נדע אם טעינו בהערכה ונוכל ללמוד להבא.
בנוסף, נדע מחיר ריאלי של עבודה.
תוספת לסעיף 4 בעקבות קריאת המאמר למטה:
אפשר לבנות את הגראף כך:
קו של תכנון מספר ה-TC פר יום / שבוע
TC שנבדקו בפועל
TC שעברו.
אם התכנון הוא על כמה TC יעברו, נניח 50, ואמנם בדקנו אפילו 55 אבל רק 45 עברו - אנו בבעייה.
5. התקדמות בבדיקות.
פרוגרסיות ברמת test case מתוכנן מול מצב בפועל
רגרסיות ברמת test case מתוכנן מול מצב בפועל
כנ"ל לגבי sanity, ATP ומה שלא יהיה שמתוכנן.
6. מדידות של דיווחי באגים.
סטאטוס: פתוח, סגור וכד'.
חומרה: קריטי, מינורי וכד' (מומלץ לשלב עם הסטאטוס).
מספר הבאגים הקיים אל מול התכנון של צפי כמות הבאגים.
7. מספר באגים אל מול test case.
יעילות ה-test case.
בטווח הארוך אולי אפשר לוותר על בדיקות מסויימות או לקצר אותו, אולי לשפר אותו.
8. מצב הדרישות.
כמה נבדקו, כמה לא, מצב באגים.
חשוב מאוד אם אנו נרצה לפתע לשחרר גרסה בדוקה חלקית נניח להמשך פיתוח אחר או לבדיקות פרוייקטליות.
9. בשלות / התכנסות הגרסה.
גרף באגים פתוחים מול סגורים (שני קווים לאורך הזמן).
אמור להתחיל עם 0 סגורים והרבה פתוחים, הסגורים יעלו הפתוחים יצטמצמו, עד ששני הקווים יפגשו, ולבסוף מעט פתוחים הרבה סגורים.
אפשר לציין בציר ה-X את תאריכי קבלת ה-buildים כדי לראות את השפעה שלהם מול קצב פתיחת הבאגים.
גם בודק את יעילות הבדיקות או ניהול גרסה: הרבה באגים שנפתחים בשלב מתקדם: האם הייתה תכולה חדשה או הבודקים לא מצאו באגים משום מה בהתחלה?
10. מספר הבאגים אל מול מספר דיווחי הבעיות מהשטח + באגים שהיו קיימים בגרסאות קודמות.
יעילות של בודקים.
11. יעילות שערים.
כמה תוכננו וכמה היו בפועל. רוצה לומר בעצם כמה בילדים מתוכנן מול קיים. אם היו יותר - מדוע?
כמה שערים עברו באיזה סטאטוס. מודד את איכות הדליברי לבדיקות.
12. זמן אי-עבודה.
הרבה פעמים העבודה נעצרת בגלל חוסר תמיכה, מעבדות לא כשירות, חוסר דרישות ועוד. יש לכמת ואח"כ להתחיל למצוא פתרונות מהקריטי לקל.
13. כמות ה-rejected bugs.
לא "עליהום" אלא להבין למה. אם בגלל טעויות של בודקים - לשפר להם את הידע הטכני והקשור לבדיקות. אולי הדרישות אינן טובות דיין.
14. באגים פר פאזה של חיי מוצר.
למשל כמה באגים על דרישות, דוקומנטציה וכד'.
15. באגים לפי ההשפעה שלהם.
פונקציונלי, התקנה ועוד.
16. באגים לפי אפליקציה / שרת.
עוד חומר אפשר למצוא כאן (תודה לדנית):
S. H. Kan, J. Parrish, and D. Manlove, In-process metrics for software testing
אין תגובות:
הוסף רשומת תגובה