סיכום המאמר שיפור תהליך הבדיקות אינו מחייב.
אני לא חושב שזהו מאמר מבריק, והוא חוזר על אותן הדוגמאות שוב ושוב, מה שמראה שהוא לא יושם כנראה באופן מלא ע"י מי שכתב אותו.
יחד עם זאת, שווה לקרוא בכדי לקבל רעיונות.
מה שבכחול - הערות שלי.
Escape - הגדרה:
escape מוגדר כבאג שעבר / לא התגלה בחדר הבדיקות אלא אצל הלקוח. כידוע באג שמתגלה בשלב זה מחירו הוא היקר ביותר. לשם כך יש לנתח את ה-escape בכדי להבין איך זה קרה, למנוע הישנות המקרה בעתיד, ולגרום לגילוי עתידי כמה שיותר מוקדם בתהליך הפיתוח.
מטרה:
להבטיח שיפורים מתמידים במוצר דרך שיפורים בתהליכי קבוצת הבדיקות והפיתוח. זה יקרה בעזרת מניעה שלאחר ניתוח הבעייה. זה ייעל את הבדיקות, יוריד את מספר הבאגים שיתגלו אצל הלקוח ולכן יוזיל את מחיר הפיתוח, יעלה את האיכות ואת השם הטוב של המוצר, ומכאן את המכירות. ככל שיותר קבוצות בחברה יהיו מעורבות בתהליך האנליזה כך הוא יהיה יעיל יותר.
התהליך מתמקד בבעיות בעלות חומרה רבה, שכילות ויקרות. מטרת אנליזת ה-escape היא:
יש לעקוב אחר הצעדים הבאים. יש לחזור עליהם בתקופות מוגדרות מראש, למשל פעם בחודש.
תכנון:
התהליך מתוכנן לעבוד הכי טוב עם כל קבוצות הפיתוח והבדיקות, אך אם זה בלתי-אפשרי ניתן ליישם בקבוצת הבדיקות.
יהיה קשה ליישם את התהליך ללא תשומת לב. לכן יש להקצות אנשים וזמן לכך. הצלחת התהליך תלוייה לחלוטין בצורת הביצוע.
לפני החלוקה לקטגוריות יש לבחור subset של escape לאנליזה. למשל אם יש ארבע רמות של חומרה של escape עדיף לנתח רק את שתי הקבוצות בעלות החומרה הגבוהה יותר. כך לא נבזבז את הזמן על בעיות שאינן כה חשובות ללקוח. בנוסף עדיף לנתח בעיות שכבר טופלו, כך נדע שהאנליזה שלהם, או ה- Root Cause Analysis הושלמה.
קטגוריזציה של escape
הצעד הראשון בתהליך הוא מיון לקטגוריות מועילות ובעלות משמעות. לצורך כך וכתנאי קודם יש להחזיק רשימה של כמה שיותר מפורטת של הבעיות. אח"כ יש להחליט אילו קטגוריות יהיו המועילות ביותר. לדוגמא:
אנליזה - כלי לניטור
יש להשתמש בכלי לניטור ותיעוד האנליזה, כמו lotus notes ואני מוסיף: אקסל כמובן.
אנליזה - סטאטיסטיקה
נועדה לעשיית שינויי high level. יש להחליט באיזו תכיפות יש לבצע אותה, פעם ברבעון נשמע סביר. בכדי לבצע אותה יש להשוות את סה"כ של כל חלק בתוך כל קטגוריה מול חלקים אחרים באותה קטגוריה. אפשרות נוספת היא הרצת סטאטיסטיקות על חלקים עם סכומים גבוהים.
אנליזה - שינויי היי-לבל בתהליך
על קבוצת אנליזת ה-escape להיפגש בכל פעם שיש אנליזה (כאמור יכול להיות פעם ברבעון) בכדי לדסקס את התוצאות. יש לזהות מגמות ולערוך סיעור מוחות על הממצאים ולמצוא שיפורים בהיי-לבל של תהליכי הפיתוח. לאחר מכן על הקבוצה לתת המלצות פורמליות לשיפורים ולערוך תוכניות לצעדי השיפור. יש לערוך ישיבות קבועות ולעקוב אחרי השינויים. בקיצור, יש לנהל את השינויים כמו ניהול של כל פרוייקט אחר. דוגמא לשינוי היא רכישה של חומרה זהה לזו של הלקוח.
אנליזה - שינויי ה-low level בתהליך
אם עובדים ברמת חברה עם כמה קבוצות, יש לבחור לקבוצת האנליזה נציג מכל קבוצה (קבוצות פיתוח, קבוצות בדיקה, הנדסת מוצר, תשתיות, מהנדס מערכת ועוד). יש להקצות escape לנציג המתאים, למשל escape שקוטלג לתהליך ה-Unit Test צריך להינתן למפתח שעורך UT להמשך האנליזה. על כל נציג קבוצה לקחת על עצמו את ה-escapes מהתחום שלו ולחזור עם הצעות שיפור. אם זה הבדיקות אז עליהם לחזור עם פעולות לשיפור שימנע את הישנות הבעייה ומקרים דומים. על תוכניות הפעולה להיות מלאות, מאושרות ואז מיושמות ויש לעקוב אחרי זה. יש להקצות תוכנית פעולה לכל escape. יש להדגיש שזה לא נועד לפתור באג ספציפי אלא לשפר תהליך. תוכנית השיפורים חייבת להיות כזו לתוריד את האפשרות לבריחת באג מאותו סוג. למשל: הוספת test case. יש לעודד יצירתיות.
מערך
הצעד האחרון בתהליך האנליזה של ה-escape הוא לערוך בכל תקופה מסויימת מדידות של שיפורים שנעשו בתהליך. זה יוסבר בהמשך.
דוגמאות
ראו תמונה 1 במאמר.
APAR = באג מהשטח.
ניתן לראות בממשק של בסיס הנתונים של לוטוס שלשה טאבים למעקב אחרי מידע ואנליזה של escape בודד. בטאב הראשון מידע מפורט אודות ה-escape. מידע זה יכול להגיע מכלי ניטור הבאגים שלנו, ואם אפשר שיגיע באופן אוטומאטי. יש להכליל היסטוריה וסיכום של הבעייה.
בתמונה 2 ניתן לראות את טאב האנליזה של הפיתוח. יש קטגוריות שונות לקלסיפיקציה של הבאג. בדוגמא הספציפית הבאג "ברח" בשלב של ה-Design Review. בכדי לתקן זאת נוספה פרוצדורה חדשה. ייתכנות התפיסה (Capture Probability) נועדה להעריך את האפקטיביות של הפתרון. האחוז אמור לענות על השאלה: מהי הסבירות שבאג זה היה מתגלה אם היינו מיישמים את הפתרון המוצע כבר אז?
יש גם שדה לקביעת תאריך הסיום.
בתמונה 3 יש דוגמא לטאב אנליזה של בדיקות. בשדה הקלסיפיקציה יש אפשרות לקבוע אם הבאג שהתגלה אצל הלקוח אכן היה escape. במילים אחרות לקבוע האם היה באמת "חור" בההליך הבדיקות או שהבאג לא היה שווה את המאמץ של מציאתו. יש לזכור שיש באגים שהם פשוט יקרים מידי למציאה, על פלטפורמות ישנות וכד'. זוהי אחריות קבוצת האנליזה של ה-escape לקבוע אם יש צורך בשינוי תהליך הבדיקות. ייתכן שלקוח חשוב כן משתמש בפלטפורמות ישנות ויש לקחת זאת בחשבון.
בדוגמא הבאג סווג תחת קטגוריה "סוג זה של בדיקה לא בוצע". לאחר הרצת סטטיסטיקה על מאות של escapes, אם יתגלה שבמקרים רבים זו הייתה הסיבה ייתכן שיש להוסיף את סוג הבדיקה הזו אפילו אם התוצאות של הבאג אינן חמורות מאוד.
מדידות
מצ"ב כמה הצעות למדידות. קודם כל יש כאן רעיונות למדידות שיכולות לתת הדרכה לצוות האנליזה של ה-escape לתוכניות פעולה לשיפורים הנדרשים. לאחר מכן יוצגו שיטות למדידת יעילות תהליך האנליזה. זה יוכל לעזור להשתמש ברעיון אחד או יותר, או להכניס מדידות משלכם.
מדידות להנעת תהליכים
מדידת סה"כ בתוך כל קטגוריה שקטלגנו במידע ויצירת תרשים שיביא את השינויים לידי ביטוי. בהמשך יש כמה דוגמאות.
תמונה 4 מראה את האחוז מסך כל ה-escapes מכל קומפוננטה של קוד. ברור מצפייה בתרשים שארבע קומפוננטות מרכיבות כ-50% מהבעיות. זה יכול לעזור לקבוצה לגלות שיש לנקוט בצעדים על מנת לשפר את הקומפוננטות הנ"ל.
תמונה 5 היא לפי השפעות על הלקוח כמו קריסה וכד'. שוב יש לפעול לפי סדר של כמותי הבעיות הרבות יותר תחילה בשילוב עם החומרה של הבעיות.
מדידת יעילות של אנליזת ה-escape
מידע מדוייק ודיווח מתמשך הכרחיים למדידת השיפורים.
TFVUD = Total Field Valid Unique Defects
כלומר סך כל הבאגים הואלידיים והסגורים שהתגלו אצל הלקוח.
PDD = Post Development Defect
באגים שהתגלו לאחר הפיתוח אבל לפני השליחה ללקוח.
KLOG = שורות של קוד באלפים.
א. TFVOD לחלק ב-KLOG קיימים וששונו.
הערך הזה אמור לקטון עם הזמן בהשוואה לגרסה אחרת באותה נקודה בתהליך.
המטרה במדידה היא לראות ירידה במספר הבעיות הואלידיות שהתגלו ע"י הלקוח יחסית למספר שורות הקוד.
ב. PDD לחלק בסך של PDD + TFVUD
הערך אמור לעלות עם הזמן בהשוואה לגרסה אחרת באותה נקודה בתהליך.
המטרה במדידה היא להניע את גילוי באגים מוקדם יותר במהלך חיי הגרסה וכך לחסוך בהוצאות.
ג. ייתכנות התפיסה
למדידה זו יש להשתמש בשדה בעל שם זה הקיים בבסיס הנתונים בטפסי ה-escape. זה יעריך את יעילות השינוי אם נמנע escape של הסוגים הנדונים. אמנם זו רק הערכה, אבל היא יכולה לשמש בסיס טוב להצגת האפקטיביות.
ניתן לסכום את ייתכנות התפיסה ומציאת ממוצע בכדי להבין את היעילות הכללית של קומפוננטה מסויימת, השפעה אצל לקוח וכד'.
כתוצאה ניתן להציג הערכה של ירידה שלבעיות בשטח.
ראו תמונה 6. לקומפוננטה B ייתכנות התפיסה של הפיתוח או הערכת האפקטיביות היא 35%. ייתכנות התפיסה של הבדיקות ל-B היא 30%. כלומר אם היו לפיתוח 100 באגים הם ימצאו 35 מתוכם. זה יותיר 65 באגים לבדיקות. אם הבדיקות ייתפסו 30% מהבאגים, כלומר 19.5, זה ס"כ הבאגים שיתגלו יהיה 35 + 19.5 שהם 55 APARים או 55% מהמאה המקוריים. 55% אלו נקראים בשם "יעילות משותפת". הנוסחה של זה נראית כך:
D = ייתכנות התפיסה של הפיתוח
T = ייתכנות התפיסה של הבדיקות
(D+(1-D)(T
המקרה שלנו:
0.35+(1-0.35)(0.30)
דוגמא זו מבוססת על קומפוננטות, אך יכולה לחול על מאפיינים אחרים גם כן - ראו תמונה 7.
הצעד האחרון הוא לשקף את הכמות שבה ניתן להוריד את הבאגים אצל הלקוח. זה נעשה ע"י סכימה ועריכת ממוצעים של ערכי היעילות משותפת. תחילה יש לבחור קבוצה של escapes שיהיו קבוצת הפוקוס של היעילות משותפת. בדוגמא הזו קבוצת הפוקוס תכלול 76 escapes. אם ערך היעילות המשותפת של 76 באגים אלה תסוכם ויעשו לה ממוצעים לדוגמא מציור 7, התוצאה תהיה 52.5% יעילות ל-76 באגים, כלומר 40 escapes שלא יגיעו ללקוח. כלומר אם היו 250 escape בשנה 16% ימנעו.
תוצאות
מטרת אנליזת ה-escape היא לשפר את איכות המוצר ושביעות רצון הלקוח, ולהוריד בהוצאות. זה נעשה ע"י גילוי הבאג כמה שיותר מוקדם. יישום התהליך ידגים את השיפורים המתמידים במקרה של אודיטים של .ISO
אני לא חושב שזהו מאמר מבריק, והוא חוזר על אותן הדוגמאות שוב ושוב, מה שמראה שהוא לא יושם כנראה באופן מלא ע"י מי שכתב אותו.
יחד עם זאת, שווה לקרוא בכדי לקבל רעיונות.
מה שבכחול - הערות שלי.
Escape - הגדרה:
escape מוגדר כבאג שעבר / לא התגלה בחדר הבדיקות אלא אצל הלקוח. כידוע באג שמתגלה בשלב זה מחירו הוא היקר ביותר. לשם כך יש לנתח את ה-escape בכדי להבין איך זה קרה, למנוע הישנות המקרה בעתיד, ולגרום לגילוי עתידי כמה שיותר מוקדם בתהליך הפיתוח.
מטרה:
להבטיח שיפורים מתמידים במוצר דרך שיפורים בתהליכי קבוצת הבדיקות והפיתוח. זה יקרה בעזרת מניעה שלאחר ניתוח הבעייה. זה ייעל את הבדיקות, יוריד את מספר הבאגים שיתגלו אצל הלקוח ולכן יוזיל את מחיר הפיתוח, יעלה את האיכות ואת השם הטוב של המוצר, ומכאן את המכירות. ככל שיותר קבוצות בחברה יהיו מעורבות בתהליך האנליזה כך הוא יהיה יעיל יותר.
התהליך מתמקד בבעיות בעלות חומרה רבה, שכילות ויקרות. מטרת אנליזת ה-escape היא:
- הפרדת ה-escape לתוך קטגוריות בכדי להקל על אנליזת העומק.
- הרצת סטאטיסטיקות על הקטגוריות הנ"ל.
- על סמך הסטאטיסטיקות הנ"ל לזהות וליישם שינויים בתהליכים.
- לזהות וליישם שינויי low level על סמך אנליזה של מקרי escape.
- לעקוב ולהציג את תוצאות השיפורים.
יש לעקוב אחר הצעדים הבאים. יש לחזור עליהם בתקופות מוגדרות מראש, למשל פעם בחודש.
תכנון:
התהליך מתוכנן לעבוד הכי טוב עם כל קבוצות הפיתוח והבדיקות, אך אם זה בלתי-אפשרי ניתן ליישם בקבוצת הבדיקות.
יהיה קשה ליישם את התהליך ללא תשומת לב. לכן יש להקצות אנשים וזמן לכך. הצלחת התהליך תלוייה לחלוטין בצורת הביצוע.
לפני החלוקה לקטגוריות יש לבחור subset של escape לאנליזה. למשל אם יש ארבע רמות של חומרה של escape עדיף לנתח רק את שתי הקבוצות בעלות החומרה הגבוהה יותר. כך לא נבזבז את הזמן על בעיות שאינן כה חשובות ללקוח. בנוסף עדיף לנתח בעיות שכבר טופלו, כך נדע שהאנליזה שלהם, או ה- Root Cause Analysis הושלמה.
קטגוריזציה של escape
הצעד הראשון בתהליך הוא מיון לקטגוריות מועילות ובעלות משמעות. לצורך כך וכתנאי קודם יש להחזיק רשימה של כמה שיותר מפורטת של הבעיות. אח"כ יש להחליט אילו קטגוריות יהיו המועילות ביותר. לדוגמא:
- Process step, כלומר היכן שהבאג היה אמור להתגלות:
בשלבי הפיתוח (מה-review של שלב המרקטינג, של מסמכי הפיתוח, דרך קוד review, דרך ה-Unit test ועוד).
בשלבי הבדיקות. - באילו קומפוננטות התגלו הבעיות.
- ה-impact של הבעיות במחינת הלקוח (קריסה, בעיות של מידע, עומס, יוזביליות וכו').
- גרסאות הקוד שבהן היו הבעיות.
- פלאטפורמה.
- חומרה.
- גרסה בה התגלו הבעיות.
אנליזה - כלי לניטור
יש להשתמש בכלי לניטור ותיעוד האנליזה, כמו lotus notes ואני מוסיף: אקסל כמובן.
אנליזה - סטאטיסטיקה
נועדה לעשיית שינויי high level. יש להחליט באיזו תכיפות יש לבצע אותה, פעם ברבעון נשמע סביר. בכדי לבצע אותה יש להשוות את סה"כ של כל חלק בתוך כל קטגוריה מול חלקים אחרים באותה קטגוריה. אפשרות נוספת היא הרצת סטאטיסטיקות על חלקים עם סכומים גבוהים.
אנליזה - שינויי היי-לבל בתהליך
על קבוצת אנליזת ה-escape להיפגש בכל פעם שיש אנליזה (כאמור יכול להיות פעם ברבעון) בכדי לדסקס את התוצאות. יש לזהות מגמות ולערוך סיעור מוחות על הממצאים ולמצוא שיפורים בהיי-לבל של תהליכי הפיתוח. לאחר מכן על הקבוצה לתת המלצות פורמליות לשיפורים ולערוך תוכניות לצעדי השיפור. יש לערוך ישיבות קבועות ולעקוב אחרי השינויים. בקיצור, יש לנהל את השינויים כמו ניהול של כל פרוייקט אחר. דוגמא לשינוי היא רכישה של חומרה זהה לזו של הלקוח.
אנליזה - שינויי ה-low level בתהליך
אם עובדים ברמת חברה עם כמה קבוצות, יש לבחור לקבוצת האנליזה נציג מכל קבוצה (קבוצות פיתוח, קבוצות בדיקה, הנדסת מוצר, תשתיות, מהנדס מערכת ועוד). יש להקצות escape לנציג המתאים, למשל escape שקוטלג לתהליך ה-Unit Test צריך להינתן למפתח שעורך UT להמשך האנליזה. על כל נציג קבוצה לקחת על עצמו את ה-escapes מהתחום שלו ולחזור עם הצעות שיפור. אם זה הבדיקות אז עליהם לחזור עם פעולות לשיפור שימנע את הישנות הבעייה ומקרים דומים. על תוכניות הפעולה להיות מלאות, מאושרות ואז מיושמות ויש לעקוב אחרי זה. יש להקצות תוכנית פעולה לכל escape. יש להדגיש שזה לא נועד לפתור באג ספציפי אלא לשפר תהליך. תוכנית השיפורים חייבת להיות כזו לתוריד את האפשרות לבריחת באג מאותו סוג. למשל: הוספת test case. יש לעודד יצירתיות.
מערך
הצעד האחרון בתהליך האנליזה של ה-escape הוא לערוך בכל תקופה מסויימת מדידות של שיפורים שנעשו בתהליך. זה יוסבר בהמשך.
דוגמאות
ראו תמונה 1 במאמר.
APAR = באג מהשטח.
ניתן לראות בממשק של בסיס הנתונים של לוטוס שלשה טאבים למעקב אחרי מידע ואנליזה של escape בודד. בטאב הראשון מידע מפורט אודות ה-escape. מידע זה יכול להגיע מכלי ניטור הבאגים שלנו, ואם אפשר שיגיע באופן אוטומאטי. יש להכליל היסטוריה וסיכום של הבעייה.
בתמונה 2 ניתן לראות את טאב האנליזה של הפיתוח. יש קטגוריות שונות לקלסיפיקציה של הבאג. בדוגמא הספציפית הבאג "ברח" בשלב של ה-Design Review. בכדי לתקן זאת נוספה פרוצדורה חדשה. ייתכנות התפיסה (Capture Probability) נועדה להעריך את האפקטיביות של הפתרון. האחוז אמור לענות על השאלה: מהי הסבירות שבאג זה היה מתגלה אם היינו מיישמים את הפתרון המוצע כבר אז?
יש גם שדה לקביעת תאריך הסיום.
בתמונה 3 יש דוגמא לטאב אנליזה של בדיקות. בשדה הקלסיפיקציה יש אפשרות לקבוע אם הבאג שהתגלה אצל הלקוח אכן היה escape. במילים אחרות לקבוע האם היה באמת "חור" בההליך הבדיקות או שהבאג לא היה שווה את המאמץ של מציאתו. יש לזכור שיש באגים שהם פשוט יקרים מידי למציאה, על פלטפורמות ישנות וכד'. זוהי אחריות קבוצת האנליזה של ה-escape לקבוע אם יש צורך בשינוי תהליך הבדיקות. ייתכן שלקוח חשוב כן משתמש בפלטפורמות ישנות ויש לקחת זאת בחשבון.
בדוגמא הבאג סווג תחת קטגוריה "סוג זה של בדיקה לא בוצע". לאחר הרצת סטטיסטיקה על מאות של escapes, אם יתגלה שבמקרים רבים זו הייתה הסיבה ייתכן שיש להוסיף את סוג הבדיקה הזו אפילו אם התוצאות של הבאג אינן חמורות מאוד.
מדידות
מצ"ב כמה הצעות למדידות. קודם כל יש כאן רעיונות למדידות שיכולות לתת הדרכה לצוות האנליזה של ה-escape לתוכניות פעולה לשיפורים הנדרשים. לאחר מכן יוצגו שיטות למדידת יעילות תהליך האנליזה. זה יוכל לעזור להשתמש ברעיון אחד או יותר, או להכניס מדידות משלכם.
מדידות להנעת תהליכים
מדידת סה"כ בתוך כל קטגוריה שקטלגנו במידע ויצירת תרשים שיביא את השינויים לידי ביטוי. בהמשך יש כמה דוגמאות.
תמונה 4 מראה את האחוז מסך כל ה-escapes מכל קומפוננטה של קוד. ברור מצפייה בתרשים שארבע קומפוננטות מרכיבות כ-50% מהבעיות. זה יכול לעזור לקבוצה לגלות שיש לנקוט בצעדים על מנת לשפר את הקומפוננטות הנ"ל.
תמונה 5 היא לפי השפעות על הלקוח כמו קריסה וכד'. שוב יש לפעול לפי סדר של כמותי הבעיות הרבות יותר תחילה בשילוב עם החומרה של הבעיות.
מדידת יעילות של אנליזת ה-escape
מידע מדוייק ודיווח מתמשך הכרחיים למדידת השיפורים.
TFVUD = Total Field Valid Unique Defects
כלומר סך כל הבאגים הואלידיים והסגורים שהתגלו אצל הלקוח.
PDD = Post Development Defect
באגים שהתגלו לאחר הפיתוח אבל לפני השליחה ללקוח.
KLOG = שורות של קוד באלפים.
א. TFVOD לחלק ב-KLOG קיימים וששונו.
הערך הזה אמור לקטון עם הזמן בהשוואה לגרסה אחרת באותה נקודה בתהליך.
המטרה במדידה היא לראות ירידה במספר הבעיות הואלידיות שהתגלו ע"י הלקוח יחסית למספר שורות הקוד.
ב. PDD לחלק בסך של PDD + TFVUD
הערך אמור לעלות עם הזמן בהשוואה לגרסה אחרת באותה נקודה בתהליך.
המטרה במדידה היא להניע את גילוי באגים מוקדם יותר במהלך חיי הגרסה וכך לחסוך בהוצאות.
ג. ייתכנות התפיסה
למדידה זו יש להשתמש בשדה בעל שם זה הקיים בבסיס הנתונים בטפסי ה-escape. זה יעריך את יעילות השינוי אם נמנע escape של הסוגים הנדונים. אמנם זו רק הערכה, אבל היא יכולה לשמש בסיס טוב להצגת האפקטיביות.
ניתן לסכום את ייתכנות התפיסה ומציאת ממוצע בכדי להבין את היעילות הכללית של קומפוננטה מסויימת, השפעה אצל לקוח וכד'.
כתוצאה ניתן להציג הערכה של ירידה שלבעיות בשטח.
ראו תמונה 6. לקומפוננטה B ייתכנות התפיסה של הפיתוח או הערכת האפקטיביות היא 35%. ייתכנות התפיסה של הבדיקות ל-B היא 30%. כלומר אם היו לפיתוח 100 באגים הם ימצאו 35 מתוכם. זה יותיר 65 באגים לבדיקות. אם הבדיקות ייתפסו 30% מהבאגים, כלומר 19.5, זה ס"כ הבאגים שיתגלו יהיה 35 + 19.5 שהם 55 APARים או 55% מהמאה המקוריים. 55% אלו נקראים בשם "יעילות משותפת". הנוסחה של זה נראית כך:
D = ייתכנות התפיסה של הפיתוח
T = ייתכנות התפיסה של הבדיקות
(D+(1-D)(T
המקרה שלנו:
0.35+(1-0.35)(0.30)
דוגמא זו מבוססת על קומפוננטות, אך יכולה לחול על מאפיינים אחרים גם כן - ראו תמונה 7.
הצעד האחרון הוא לשקף את הכמות שבה ניתן להוריד את הבאגים אצל הלקוח. זה נעשה ע"י סכימה ועריכת ממוצעים של ערכי היעילות משותפת. תחילה יש לבחור קבוצה של escapes שיהיו קבוצת הפוקוס של היעילות משותפת. בדוגמא הזו קבוצת הפוקוס תכלול 76 escapes. אם ערך היעילות המשותפת של 76 באגים אלה תסוכם ויעשו לה ממוצעים לדוגמא מציור 7, התוצאה תהיה 52.5% יעילות ל-76 באגים, כלומר 40 escapes שלא יגיעו ללקוח. כלומר אם היו 250 escape בשנה 16% ימנעו.
תוצאות
מטרת אנליזת ה-escape היא לשפר את איכות המוצר ושביעות רצון הלקוח, ולהוריד בהוצאות. זה נעשה ע"י גילוי הבאג כמה שיותר מוקדם. יישום התהליך ידגים את השיפורים המתמידים במקרה של אודיטים של .ISO
אין תגובות:
הוסף רשומת תגובה