איך בודקים את הבודקים

הקדמה

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

הגדרת הבעיה

הבעיה המרכזית בהערכת איכות בדיקות התוכנה היא התלות של הבדיקות בגורמים “חיצוניים”. גם כאשר ארגונים מיישמים מתודולוגיות רוחביות על כל השלבים במחזור חיי מערכת, עדיין התהליך – ברוב המקרים – רחוק מלהיות אופטימאלי: הזמנים המוגדרים להקמת מערכת גדולה ומורכבת הם לרוב קצרים בהרבה מהנדרש ואינם ריאליים, שינויים שוטפים לתכולת המערכת מתקבלים ללא בקרה בכל שלבי מחזור חיי המערכת אבל לוחות הזמנים לרוב אינם מתעדכנים, מסמכי המערכת אינם שלמים ו/או מדויקים, לא תמיד קיימת עזרה לצורך הבהרות פעילות המערכת החדשה ועוד.

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

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

פתרונות

[1] יעילות תרחישי הבדיקות

א. נוסחה זו מייצגת את אחוז התרחישים ש”גילו” תקלות

 מספר תרחישי בדיקות / (100 * מספר תקלות שנתגלו) = יעילות

ב. נוסחה זו מייצגת את אחוז התקלות שנתגלו ללא קשר לתרחישים שתוכננו ובוצעו

מספר תקלות כולל / (100 * מספר תקלות שנתגלו ללא תרחישים) = יעילות

ג. נוסחה זו מייצגת את אחוז התקלות שהוגדרו כ”לא נכונות”

סך התקלות שנתגלו / (100 * מספר תקלות כפולות + מספר תקלות שנדחו) = יעילות

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

המלצות: הדרך היעילה ביותר לשימוש במדדים אלו היא על-ידי השוואתם ל”מדדי-יעד” המייצגים “תרחישים טובים”. מדדי יעד אלו חייבים לכלול גם את כל המרכיבים בתהליך הפיתוח אשר משפיעים על איכות הבדיקות.

[הערה: מדדי יעד ראשוניים עלולים לא להיות מדויקים, וידרשו עדכונים עד לקבלת ערכים ריאליים על בסיס ניסיון]

[2] הערכות קלאסיות

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

T/(T+P))*100 = (85/(85+16)*100 = 84.16%) =יעילות הבדיקות

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

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

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

[3] איכות הבדיקות ביחס לאיכות הפיתוח

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

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

לפי הדוגמא הזו, איכות הפיתוח של המערכת, ביחס לפרמטרים המשפיעים על הבדיקות, היא 55.7%

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

בצעד 1 הגדרנו את איכות הפיתוח ביחס להשפעות על הבדיקות, ומצאנו בדוגמא שהאיכות היא 55.7%. פירוש הדבר, שעבור הבדיקות המבוצעות על מערכת זו, ערכי היעד יהיו כמוגדר בטור 51-75 של הטבלה למעלה.

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

חולשות:

אמנם צעדים 1 + 2 הם חד-פעמיים, הם אינם פשוטים להגדרה. בנוסף, גם מדד זה ניתן למדידה רק לאחר סיום פעילות הבדיקות.

סיכום

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