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

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

Ramona Schwering

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• התבנית Arrange, act, assert. דפוס הבדיקה 'ארגון, ביצוע, טענה' (שנקרא גם 'AAA' או 'טריפל A') הוא דרך לארגן בדיקות בשלושה שלבים נפרדים: ארגון הבדיקה, ביצוע הבדיקה ולבסוף, חשוב לא פחות, הסקת מסקנות.
• התבנית Given, when, then. התבנית הזו דומה לתבנית AAA, אבל יש לה שורשים מסוימים בפיתוח מבוסס-התנהגות.

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

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

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