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