הבעיה שה-ODC באה לפתור היא העדר מידע אובייקטיבי לגבי איכות הגרסה והאפקטיביות של הפיתוח ושל הבדיקות. היישום שלה יענה לשאלות איפה ולמה הבאגים נוצרים ואיך לתקן את הטעון תיקון.
בדרך כלל איכות הגרסה נקבעת כטובה כשבבדיקות מפסיקים לגלות באגים חדשים, אין באגים קריטיים פתוחים, עד כמות n של באגים מאג'וריים וכמות y של באגים מינוריים. בנוסף, כשיש באגים שנמצאו בשטח אנו בודקים את הסיבה שהוא הגיע לשם, אך בצורה בודדת של מקרים בודדים.
לעומת זאת ה-ODC (ויש לציין שהוא אינו מבטל את המדדים ה"רגילים") עלותו נמוכה יחסית אבל ליכולות שלו והוא מתרכז בכמויות, או במבט מלמעלה כביכול.
בכדי ליישם אותו קודם כל יש לבצע פיילוט על נתונים מגרסה אחורה או יותר, על ידי מישהו המכיר את כללי הקלסיפיקציה או שעובד כשהם לנגד עיניו (ראי כאן). אם הפיילוט מוצלח יש להגדיר את הפרויקט הבא, להעביר הדרגה לפיתוח ולבדיקות.
אני הייתי חלק מתהליך יישום של המתודה הזו. כאן אני רוצה להתרכז בעיקר בקלסיפיקציה בבדיקות, ונקודתית יותר אני רוצה לדבר על ה-impact.
הרעיון של קלסיפיקציה של ה-impact הוא זה: בכתיבה רגילה של דיווח תקלה, או באג, אנו רושמים בין היתר את תסמיני הבעיה (למשל "לחיצה על "שמירה" אינה שומרת את המסמך"), אבל איננו מתייחסים לסוג השפעה שיש לה כל המשתמש (בין אם קצה ובין אם לא). למשל בדוגמת חוסר האפשרות לשמור ה-impact שלה היא ה-capability של המוצר.
למשל הזמן בין השליחה של שם המשתמש והסיסמא לכניסה לאתר בפועל ארוך מידי. ה-impact כאן הוא Performance.
נניח ש-80% מהגרסה, וזה מצב הבאגים שנפתחו מבחינת ה-impact:
1. Installability : 18/2
2. Serviceability: 23/13
3. Standards: 4/0
4. Integrity/Security: 6/0
5. Migration: 15/2
6. Reliability:30/11
7. Performance: 2/1
8. Documentation: 9/2
9. Requirements: 13/3
10. Maintenance: 1/1
11. Usability: 4/2
12. Accessibility: 8/0
13. Capability: 38/8
למשל בעיות התקנה: 18 דיווחי באגים נפתחו, 2 עדיין פתוחים.
אפשר לראות ששלושת הבעיות העיקריות שהתגלו היו ב- Capability, ב- Reliabilityוב- Serviceability.
עכשיו אפשר לפרק ולהצליב עם מידע כמו הקומפוננטות הרלוונטיות בהן יש יותר בעיות מהסוגים הנ"ל, לשאלה אם הבעיות הן בקוד חדש או ישן וכד'. מכאן התובנות צריכות להיות שלכם.
כשמסתכלים על כמות הבאגים הקיימים כרגע במערכת (הפתוחים) ברור ש11 באגים האמינות = גרסה לא בוגרת מספיק. יכול להיות שאין באגים קריטיים ורק 20 בסה"כ מאג'וריים, אבל זו אינה כל האמת, האמת היא שיש בעיית אמינות במערכת.
דבר מעניין שאפשר לעשות הוא לסווג את מסמכי הבדיקות לפי ה-impact. ואז נשאל שאלות כגון אלה:
• האם מרבית הבאגים התגלו ב"ריצה" על המסמכים או בבדיקות חופשיות?
• האם אנו בודקים מספיק את נושא האמינות ושאר המקומות המועדים לפורענות?
• האם אנו מדוחים על באגים בדרישות
וכו'.
אני חייב לומר שהתוצאות אצלנו היו מפתיעות, ושהמדדים הללו עזרו לנו לשפר את התהליך.
בדרך כלל איכות הגרסה נקבעת כטובה כשבבדיקות מפסיקים לגלות באגים חדשים, אין באגים קריטיים פתוחים, עד כמות n של באגים מאג'וריים וכמות y של באגים מינוריים. בנוסף, כשיש באגים שנמצאו בשטח אנו בודקים את הסיבה שהוא הגיע לשם, אך בצורה בודדת של מקרים בודדים.
לעומת זאת ה-ODC (ויש לציין שהוא אינו מבטל את המדדים ה"רגילים") עלותו נמוכה יחסית אבל ליכולות שלו והוא מתרכז בכמויות, או במבט מלמעלה כביכול.
בכדי ליישם אותו קודם כל יש לבצע פיילוט על נתונים מגרסה אחורה או יותר, על ידי מישהו המכיר את כללי הקלסיפיקציה או שעובד כשהם לנגד עיניו (ראי כאן). אם הפיילוט מוצלח יש להגדיר את הפרויקט הבא, להעביר הדרגה לפיתוח ולבדיקות.
אני הייתי חלק מתהליך יישום של המתודה הזו. כאן אני רוצה להתרכז בעיקר בקלסיפיקציה בבדיקות, ונקודתית יותר אני רוצה לדבר על ה-impact.
הרעיון של קלסיפיקציה של ה-impact הוא זה: בכתיבה רגילה של דיווח תקלה, או באג, אנו רושמים בין היתר את תסמיני הבעיה (למשל "לחיצה על "שמירה" אינה שומרת את המסמך"), אבל איננו מתייחסים לסוג השפעה שיש לה כל המשתמש (בין אם קצה ובין אם לא). למשל בדוגמת חוסר האפשרות לשמור ה-impact שלה היא ה-capability של המוצר.
למשל הזמן בין השליחה של שם המשתמש והסיסמא לכניסה לאתר בפועל ארוך מידי. ה-impact כאן הוא Performance.
נניח ש-80% מהגרסה, וזה מצב הבאגים שנפתחו מבחינת ה-impact:
1. Installability : 18/2
2. Serviceability: 23/13
3. Standards: 4/0
4. Integrity/Security: 6/0
5. Migration: 15/2
6. Reliability:30/11
7. Performance: 2/1
8. Documentation: 9/2
9. Requirements: 13/3
10. Maintenance: 1/1
11. Usability: 4/2
12. Accessibility: 8/0
13. Capability: 38/8
למשל בעיות התקנה: 18 דיווחי באגים נפתחו, 2 עדיין פתוחים.
אפשר לראות ששלושת הבעיות העיקריות שהתגלו היו ב- Capability, ב- Reliabilityוב- Serviceability.
עכשיו אפשר לפרק ולהצליב עם מידע כמו הקומפוננטות הרלוונטיות בהן יש יותר בעיות מהסוגים הנ"ל, לשאלה אם הבעיות הן בקוד חדש או ישן וכד'. מכאן התובנות צריכות להיות שלכם.
כשמסתכלים על כמות הבאגים הקיימים כרגע במערכת (הפתוחים) ברור ש11 באגים האמינות = גרסה לא בוגרת מספיק. יכול להיות שאין באגים קריטיים ורק 20 בסה"כ מאג'וריים, אבל זו אינה כל האמת, האמת היא שיש בעיית אמינות במערכת.
דבר מעניין שאפשר לעשות הוא לסווג את מסמכי הבדיקות לפי ה-impact. ואז נשאל שאלות כגון אלה:
• האם מרבית הבאגים התגלו ב"ריצה" על המסמכים או בבדיקות חופשיות?
• האם אנו בודקים מספיק את נושא האמינות ושאר המקומות המועדים לפורענות?
• האם אנו מדוחים על באגים בדרישות
וכו'.
אני חייב לומר שהתוצאות אצלנו היו מפתיעות, ושהמדדים הללו עזרו לנו לשפר את התהליך.
אין תגובות:
הוסף רשומת תגובה