מדריך לניהול תקלות בתהליך הבדיקות

שלב 1: גילוי התקלות

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

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

כמנהל בדיקות, מה תעשה?

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

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

שלב 2: סיווג תקלות

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

תרגול:

סווג את העדיפויות עבור התקלות הבאות:

ביצועי האתר איטיים מדי
פונקציית ההתחברות אינה פועלת כראוי
ממשק המשתמש אינו מוצג כראוי במכשירים ניידים
האתר אינו זוכר את פרטי התחברות המשתמש
חלק מהקישורים באתר אינם עובדים

תשובות מומלצות:

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

שלב 3: פתרון תקלות

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

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

שלב 4: אימות

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

שלב 5: סגירת תקלות

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

שלב 6: דיווח תקלות

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

מדדי תקלות חשובים

מדד 1: יחס דחיית תקלות (Defect Rejection Ratio – DRR):
מדד זה מחושב לפי היחס בין מספר התקלות שנדחו לבין כלל התקלות שדווחו.
לדוגמה: אם נדחו 20 תקלות מתוך 84, DRR = 20/84 = 0.238 (23.8%).

מדד 2: יחס דליפת תקלות (Defect Leakage Ratio – DLR):
מדד זה מחושב לפי היחס בין מספר התקלות שלא אותרו בבדיקות לבין כלל התקלות הקיימות.
לדוגמה: אם באתר יש 64 תקלות, וצוות הבדיקות איתר רק 44, DLR = 20/64 = 0.312 (31.2%).

המדדים האלו משמעותיים מכמה סיבות:

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

סיכום

כדי לשפר את איכות הבדיקות ולהקטין את ערכי DRR ו-DLR:

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