מתי לסיים את הבדיקות
הקדמה
העובדה היא: אין 100% בדיקות. ראשית, משום ש- 100% בדיקות משמעו (לפחות בתיאוריה) אין-סוף תרחישים. שנית, משום ש”זמן זה כסף” וגם שלב בדיקות התוכנה, כמו כל שלב אחר בחיי המערכת, מוגבל בזמן.
עובדה זו גוררת את הצורך בפשרות במהלך תהליך הבדיקות, ולכן – בדיקות תוכנה “טובות” הן אלו שהפשרות הכלולות בהן מביאות בחשבון את הסיכונים הנלווים, בדיקות המבטיחות שכל אותן פשרות לא יגרמו לסיכון חיי אדם, איבוד כסף או יסתיימו במערכת לא שמישה.
מאמר זה דן במספר שיטות להגדרת “סיום הבדיקות” תוך ציון החולשות של כל שיטה וכן מתן המלצות לגישור הפערים כאשר אפשר.
חברות וארגונים משתמשים בשיטות שונות לכמת את איכות המערכת לצורך הערכה והחלטה על סיום הבדיקות. חלק מהשיטות הן “גמישות”, כלומר, מתבססות על הערכת איכות המערכת ומתייחסות לסיכונים. שיטות אחרות הן “קשיחות”, וזה אומר שהן לא מביאות בחשבון סיכונים או הערכה של איכות המערכת אלא רק מתייחסות לזמן ולהשקעה.
אף אחת משיטות אלו איננה מושלמת או לגמרי מדויקת, וכל שיטה יכולה להתאים לסוגי מערכות וארגונים שונים.
שיטות “גמישות”
[1] המדד הקלאסי לסיום בדיקות התוכנה
רוב מתודולוגיות הבדיקות מציגות את הגישה הזו כמדד קלאסי לקביעת סיום הבדיקות על בסיס איכות המערכת, כאשר איכות המערכת נמדדת לפי התקלות הפתוחות (כאלו שלא נפתרו עדיין).
א. מקסימום תקלות פתוחות (שלא תוקנו ולא נפתרו) לפי דרגות חומרה:
| תקלות קריטיות | תקלות חמורות | תקלות בינוניות | תקלות מינוריות |
| 0 | <2% מסך התקלות | < 5% | < 8% |
ב. מינימום תרחישי בדיקות שבוצעו וכאלו שעברו בהצלחה:
| % התרחישים שבוצעו מתוך אלו שתוכננו | > 85% |
| % תרחישים שעברו בהצלחה מתוך אלה שבוצעו | > 95% |
[הערה: המספרים המיוצגים בטבלאות הנ”ל הם לצורך דוגמא בלבד.]
חולשות:
המדדים האלו לא מייצגים בצורה נכונה את כל נושאי/חלקי המערכת. לדוגמא: תקלה קריטית בהפקת דו”ח שנתי לא תהווה בהכרח סיבה לביצוע סבב בדיקות נוסף. לעומת זאת, תקלה בינונית שנמצאה בפעילות דף Web המשמש לקוחות עלול להוות סיבה משמעותית לבדיקות חוזרות.
המלצה:
הרחבת המדדים האלו, והוספת קריטריונים שונים לנושאי מערכת בעלי תיעדוף שונה. (תיעדוף: ערך מספרי המייצג “חשיבות”). למשל:
| תיעדוף | תקלות קריטיות | תקלות חמורות | תקלות בינוניות | תקלות מינוריות |
| 1 | 0 | < 2% | < 5% | < 8% |
| 2 | 0 | < 4% | < 8% | < 10% |
| 3 | < 2% | < 5% | < 10% | < 12% |
| תיעדוף | 1 | 2 | 3 |
| % התרחישים שבוצעו מתוך אלו שתוכננו | > 95% | > 90% | > 85% |
| % תרחישים שעברו בהצלחה מתוך אלה שבוצעו | > 85% | > 80% | > 75% |
[הערה: לפי הדוגמא כאן, ערך תיעדוף 1 = סיכון גבוהה, ערך תיעדוף 3 = סיכון מינורי]
לצורך זה צריך, כמובן, לתעדף את כל נושאי המערכת הנבדקים בצורה שתייצג את הסיכון שהתקלות גוררות, בהיבט הפיננסי, היבט תפעולי, מוניטין וכד’.
[2] “הכי פשוט”?
השיטה נקראת “Go / NoGo”, ולפי שיטה זו, בסיום כל סבב בדיקות, ראש צוות הבדיקות, מנהל המוצר, נציג פיתוח, נציג משתמשים – או כל צוות אחר שייבחר, יעבור על כל דיווחי התקלות, יחליט ויסמן כל התקלה עם:
- “Go” – במידה וניתן להערכתם, להעביר את המערכת לייצור גם ללא תיקון התקלה
- “NoGo” – במידה וחייבים לתקן את התקלה הזו.
כל עוד ישנן תקלות המסומנות ב- “NoGo”, הבדיקות יימשכו בהיקפים שונים על-פי המצב.
חולשות:
סבבי הבדיקות עלולים להמשך זמן רב מהצפוי, ולעבור את התאריך המתוכנן של העלייה לאוויר.. בנוסף, השיטה הזו כרוכה בהשקעת זמן רבה, לקרוא ולהבין את המשמעויות של כל תקלה ותקלה.
יתרונות:
השיטה מתייחסת לסיכונים שכל תקלה גוררת, ומאפשרת צמצום הבדיקות בסבבים השונים.
[3] Isoquant של סיכון סביר
גרף ה- Isoquant מציג את כל הקומבינציות האפשריות של קלטים אשר נותנים תוצאה זהה. לדוגמא:
אם נשתמש בשיטה זו להעריך את איכות המערכת על-בסיס סיכון, הגרף עשוי להיראות כך:
הסיכון המוגדר יכול להיות כל סיכון רלוונטי: סיכון בשימושיות המערכת, סיכון פיננסי, טכני וכד’ או קומבינציה של כמה פרמטרים.
לאחר הגדרת הסיכון בגרף, ההחלטה על סיום הבדיקות יכולה להיות בכל נקודה על הגרף, כאשר כל נקודת סיכון מייצגת את היחס בין כמות התקלות לממוצע החומרה שלהן.
חולשות:
למרות שהשיטה מתייחסת לסיכונים, היא משאירה פתח לסיכון של תקלה מאוד קריטית שעלולה להתגלות ולגרום לנזקים.
יתרונות:
השיטה הזאת דומה לשיטות הקודמות, כי גם היא מתייחסת – הן לאיכות המערכת והן לסיכונים בסיום הבדיקות.
שיטות “קשיחות”
[1] לוח זמנים ו/או מספר סבבים
הרבה מאוד ארגונים קובעים מראש את הלוז לסיום הבדיקות, לוז שאין לחרוג ממנו, ויש אחרים שקובעים מספר סבבי ביצוע בדיקות שהוא קשיח במידה דומה. לפי שתי השיטות האלו – הבודקים חייבים לעשות את הטוב ביותר עד לתאריך היעד, ולתת דגש לסיכונים שבתקלות שלא התגלו..
השיטה מתאימה למערכות שאינן כרוכות בסכנה לחיי אדם, כמו למשל מערכות רפואיות שונות, אם כי ראיתי גם הרבה ארגונים אחרים שעובדים בצורה דומה.
חולשות:
למרות שרואים את זה בהרבה ארגונים, זוהי שיטה שעלולה לגרור נזק רציני למשתמשי המערכת הנבדקת, כי חסר כאן פרמטר שקובע סיום בדיקות ומתייחס לתפקוד המערכת ולאיכות שלה.
[2] הערכה שוטפת
תקלות מתנהגות, ברוב המקרים, בצורה צפויה, ולכן ההחלטה על סיום הבדיקות ניתנת לקביעה מראש על-פי הצפי של התקלות:
חולשות:
תלות בהתנהגות צפויה של תקלות נראית מסוכנת מדי, ואינה מאפשרת התייחסות למצבים חריגים ולא צפויים. חולשה מרכזית נוספת היא, חוסר ההתייחסות לסיכונים הכרוכים בסיום הבדיקות. המדד הזה מתמקד אך ורק בכמות התקלות הצפויות ללא ניתוח הנזקים שהן עלולות לגרום.
סיכום
אין שיטה אחת ברורה ומוחלטת. אבל – ההחלטה על סיום הבדיקות חייבת תמיד להביא בחשבון את הסיכונים הכרוכים בזה, גם משום שאין מערכת ללא תקלות וגם משום שאין 100% בדיקות ולכן נזק תמיד צפוי.
ואם בוחרים שיטה לקביעת סיום בדיקות שאיננה מתייחסת לסיכונים או לאיכות המערכת, כדאי מאוד להבטיח שהבדיקות עצמן הן בדיקות איכותיות, ושבזמן המוקצב לתכנון וביצוע הבדיקות משיגים את המקסימום האפשרי.
