fbpx

גישת ניחוש שגיאות

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

  • טכניקות קופסה שחורה המבוססות על המפרטים הטכניים (Specification Based)
  • טכניקות קופסה לבנה המבוססות על מבנה הקוד של התוכנה (Structure Based)
  • טכניקה מבוססת ניסיון (Experienced Based) שנחשבת גם לטכניקת קופסה שחורה כשאחת השיטות המוכרות בה היא בדיקות המבוססות על ניחוש שגיאות.

 

מהי השיטה?

שיטה זו מבוססת למעשה על ניחוש אינטליגנטי של מיקומי תקלות אפשריות שניתנות לחיזוי.

ה"ניחוש" מתבסס על היכרות מוקדמת עם המערכת או היכרות עם מערכות ממוחשבות דומות.

יכולת הניחוש נרכשת בהתאם לפרמטרים הבאים:

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

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

 

כיצד נבצע את הבדיקות בשיטה זאת?

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

גישת ניחוש שגיאות

 

דוגמה

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

א. רכישת מוצרים אונליין   (Online Purchase of Products)

ב. מעקב מקוון אחרי הזמנות (Online tracking of shipments)

 

יתרונות השיטה

  • יתרון מובהק הוא שהשיטה פשוטה יחסית ומתבססת על ניסיון העבר ככלי לזיהוי אזורים בעלי סיכון.
  • השיטה מאתגרת את המוצר ומאפשרת להגיע לאזורי בדיקה שאולי היינו מפספסים בשיטות פורמליות יותר.
  • השיטה מאפשרת להגיע לתקלות שהיינו מוצאים רק בבדיקות מקיפות יותר ולכן היא מסייעת באיתור מוקדם של באגים ועל כן מקצרת ומייעלת את סבב הבדיקות וכך חוסכת במקרים רבים זמן וכסף (עלות תיקון).
  • שיטת ניחוש שגיאות יכולה לשמש בסיס מצויין לבדיקות חוקרות Exploratory Testing ולהוות גם בסיס לכתיבת מקרי בדיקה Test Cases מסודרים כפי שאנו מבצעים מול מפרטים טכניים.

חסרונות השיטה

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

 

לסיכום

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

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

רוצה שנדבר בWhatsapp?