הגדרת מקרי בדיקה וסדרי עדיפויות

קובעים מה לבדוק, מגדירים את מקרי הבדיקה וקובעים סדר עדיפויות.

Ramona Schwering

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

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

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

מהו מקרה בדיקה?

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

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

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

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

נתיבי בדיקה: סוגים אופייניים של מקרי בדיקה

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

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

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

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

יש כמה שיטות לסווג את הנתיבים האלה. שתי גישות נפוצות הן:

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

שיטה מומלצת: כתיבת מקרי מבחן

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

• לארגן, לפעול, לטעון דפוס. דפוס הבדיקה של "לארגן, לפעול, להצהיר" (נקרא גם "AAA" או "Triple A") הוא דרך לארגן בדיקות לשלושה שלבים נפרדים: סידור הבדיקה, לאחר מכן ביצוע הבדיקה, ולבסוף, הסקת מסקנות.
• ניתן, מתי ואז קו ביטול נעילה. הדפוס הזה דומה לדפוס AAA, אבל יש לו כמה שורשים בפיתוח מבוסס-התנהגות.

במאמרים הבאים נפרט יותר על הדפוסים האלה ברגע שנעבור על המבנה של הבדיקה עצמה. אם אתם רוצים להתעמק בדפוסים האלה בשלב הזה, כדאי לקרוא את שני המאמרים האלה: Arrange-Act-Assert: Arrange-Act-Assert: A template forכתיבת בדיקות טובות ומתי-אז.

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

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