בדיקות במתודולוגיה זריזה
בפיתוח תוכנה זריז מבצעים פיתוח איטרטיבי ואינקרמנטלי של תוכנה, המבוסס על רעיון של זריזות וגמישות הפיתוח. יש חשיבות לזריזות וגמישות על פני ניתוח ואפיון מפורט. הכלי אשר משמש לתיעוד הדרישות הוא סיפור משתמש. כלי זה הוא מתומצת וקצר. חוץ ממנו לא קיימים עוד כלים לתיעוד הדרישות. בבדיקות תוכנה מבוססות פיתוח זריז נעזרים במידע של מקרי בדיקה עסקיים, הן בשביל בדיקות והן בשביל תמיכה בפיתוח כפיצוי על חוסר האפיון המפורט.
תפקיד הבודקים העיקרי הוא לקחת סיפור משתמש ולהפוך אותו לבדיקות על ידי יצירת מקרי בדיקה. רוב הבדיקות האלו עוברות אוטומציה ונשמרות כדי לאפשר בדיקות רגרסיה. בדיקות מסורתיות נעשות מול קוד שנכתב עם האפיון המפורט, אך הם לא קיימים בפיתוח זריז. לא ניתן לערוך בדיקות מסורתיות בלי ספציפיקציות, ולכן עריכת בדיקות מסורתיות במתודולוגיה זריזה אינו אפשרי. סיפורי משתמש הם קצרים, מועטים ולא תמיד מספיקים למפתחים כדי להבין את הדרישות הפונקציונליות במלואן.
בגלל שאין דרישות מפורטות, ואין גם ספציפיקציות בפיתוח תוכנה זריז מקרי הבדיקה העסקיים (הנקראים גם ספציפיקציות ניתנות להרצה), משמשים גם לבדיקות רגרסיה, וגם כעזרה לפיתוח.
בדיקות בשלבי פיתוח תוכנה זריז
- Sprint 0: שלב שמבוצעת בו הכנה, וגם קונפיגורציה של סביבה ומסגרת הבדיקות.
- Iteration: כולל מספר sprint אשר כוללים פונקציונליות שנחשבת ציון דרך לעסק.
- sprint i: כל שלב נבחרים סיפור משתמש בעלי עדיפות גבוהה. הבודקים והמפתחים עובדים במקביל וקיימת תקשורת ביניהם ובין המנתח העסקי.
- release: נקודה שבה מסתיימת פיתוח האיטרציה והפונקציונליות הנדרשת.
- UAT: כאן צריך לבדוק את התוצר של האיטרציה. המשתמש או הלקוח צריך לבדוק את התוצר. מקרי הבדיקה העסקיים עוזרים לאשר לו את טיב התוצר. בדיקות ידניות יכולות להתבצע כהכנה לשלב זה.
בדיקות בשלב sprint
בודק תוכנה: לוקח ובונה מקרי בדיקה עסקיים. מכיוון שסיפורי משתמש הם בעלי אינפורמציה מועטה הוא עובד צמוד עם מנתח עסקי או מומחה דומיין, כדי ליצור מקרי בדיקה טובים. הבודק צריך להגדיל ראש ולכסות כמה שיותר תסריטים. את מקרי הבדיקה הוא כותב במסגרת עבודה של בדיקות.
מקרי בדיקה עסקיים: מקרי בדיקה המוסברים במונחים של תחום העסק הנקראים גם "ספציפיקציות ניתנות להרצה".
מסגרת העבודה של בדיקות מאפשרת להפוך את הבדיקות לאוטומטיות. כדי לעשות זאת הבדיקות נכתבות בסביבת העבודה, ובאמצעות ה FIXTURES מחוברות עם קוד האפליקציה. לבסוף ניתן להריץ את הבדיקות מול האפליקציה (Application Under Test), ולהחזיר תוצאות. קיימות מספר מסגרות בדיקה כגון FIT, Fitness, Concordian ועוד.
Fixtures: נכתבים במסגרת הבדיקות מטרתם היא לקשר בין המקרי בדיקה העסקיים ל AUT. בדרך כלל יש צורך בידע תכנותי כדי ליצור אותם, אך לא תמיד לבודק יש ידע כזה.
המפתח: בפיתוח תוכנה זריז אין דרישות פונקציונליות מפורטות, לכן המפתח נעזר במקרי בדיקות עסקיות. הוא יוצר יחידת בדיקה בדומה ליצירתם בפיתוח מונחה בדיקות. בדיקות אלו הופכות לאוטומטיות על ידי כלים כמו JUnit .
יש צורך במקרי בדיקה עסקיים שיכסו מספיק מקרים אפשריים כך שיהיה למפתחים אינפורמציה, וגם הבדיקה תהיה מספיק טובה. בדרך זו ניתן לעשות אוטומציה למקרי בדיקה עסקיים ובדיקות יחידה אשר ביחד משמשים לבדיקות רגרסיה מתמשכות. הרבה בדיקות מסובכות וקשות ליישום ולכן חלק מהבדיקות לא עוברות אוטומציה וחלקן מבוצעות ידנית בסוף sprint.
ראו גם
קישורים חיצוניים
- Russell O'Brien, Agile Testing Explained 2011,
- agile testing with lisa crispin(הקישור אינו פעיל),
28497383בדיקות במתודולוגיה זריזה