Orthogonal Defect Classification - ODC - חלק שני

הבעיה שה-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. ואז נשאל שאלות כגון אלה:
• האם מרבית הבאגים התגלו ב"ריצה" על המסמכים או בבדיקות חופשיות?
• האם אנו בודקים מספיק את נושא האמינות ושאר המקומות המועדים לפורענות?
• האם אנו מדוחים על באגים בדרישות
וכו'.

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

Orthogonal Defect Classification - ODC - חלק ראשון

המאמר המקורי מכאן.

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

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

תהליך הישום של ה-ODC:

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

מיון ואימות של הבאגים

ישנן שתי נקודות של מיון.

הראשונה כשהבאג מתגלה. מגלה הבאג ממלה מאפיינים של הפעילות (activity) בה התגלה הבאג, מה שעורר (trigger) אותו, והשפעה (impact) שלו.

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

השנייה היא בעת תיקון הבאג. המאפיינים הם המטרה (target), סוג הבאג (type), המתאר (qualifier), מקור (source) וותק (age).

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

למידע נוסף לחצי כאן.

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

הערכת המידע

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

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

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

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

סמכות מול מנהיגות והשטחים האפורים

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

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

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

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


מסקנה: צריך לא רק לדעת איך להרשים, אלא גם את מי.

העבודה מול הפיתוח

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

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

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

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

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

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

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

· הם לא מכירים את המערכת עד הסוף.

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

· לא ברור בכלל מדיווחי הבאגים מה הבעיה, אין לוגים וכד'.

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

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

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

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

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

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

Unit Tests

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

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

מסיבה זו אני אכנס מעט לתהליכים שבד"כ אנו לא מעורבים בהם.

הראשון הוא ה-unit test, להלן UT.

Unit Tests

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

אחריות וביצוע: פיתוח.

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

מומלץ לכתוב את ה-UT לפני כתיבת הקוד עצמו.

מטרות:

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

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

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

בדיקות טובות של UT הן:

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

כמו תמיד, יש לעשות review על כל בדיקה ומידי פעם על ה-scope של הבדיקות, כיסוי האזורים וכד'. שני הדברים האחרונים – בתיאום עם מחלקת הבדיקות.

נקודות נגד:

מאריך את זמן הפיתוח, לא תמיד קל ליישום.

הערה: נעזרתי בויקי באנגלית: http://en.wikipedia.org/wiki/Unit_test שם יש חלק נוסף הקושר בין ה-UT ל-Extreme Programming.