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

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

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

בסיס השוואה חשוב יותר משיפור לכאורה#

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

להפריד סט פיתוח מסט מבחן#

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

גודל מדגם ומה אי אפשר להסיק ממנו#

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

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

משקל סיכון ולא רק ממוצע#

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

תהליך בדיקת שינוי מושכל#

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