עדיין מהספר Agile testing
אם נבין את המטרות של הבדיקות, נבין אילו סוגי בדיקות אנו צריכים ונבין מתי מיצינו את סוגי הבדיקות.
הסופרות של הספר הנ"ל מחלקות את הבדיקות לארבעה רבעים
שני הסוגים השמאליים הם בדיקות התומכות בפיתוח. בלשון הסופרות הכוונה בבדיקות שנעשות ביחד עם הפיתוח ועוזרות לו. בדיקות אלה הן ההבדל המהותי בבדיקות מסורתיות מול בדיקות אג'ייל סטייל.
הרבע הראשון הוא כולו אוטומטי ונקרא לפעמים TDD, test driven development. אלו בדיקות של קוד שנכתבות לעיתים טרם נכתב הקוד.
הבדיקות כוללות unit tests, בדיקת החלקים הבסיסיים ביותר במערכת, ובדיקות של כמה יחידות כאלה שנקראות component tests.
בדיקות הרבע השני גם תומכות בפיתוח, אך ברמה גבוהה יותר. בדיקות אלה נקראות גם business/customer-facing tests ובודקות את האיכות והפיצ'רים שהלקוח ביקש. כאן נבדק קוד שהלקוח איפיין. הבדיקות מדגימות את התנגדות התוכנה ברמה גבוהה.
מלבד בדיקות ה-UI, בדיקות אלו צריכות להיות אוטומאטיות.
למעשה התגובה האוטומטית המהירה של שני הרבעים הראשונים לאחר כל שינוי קוד היא מיסודות של קבוצת אג'ייל.
בדיקות שמבקרות את המוצר
ישנם אספקטים אחרים למוצר, חלקם אינם באים ישירות מדרישות הלקוח, כמו בדיקות security, יוזביליטי וכד'. עלינו להשתמש בבדיקות מסוג אחד בכדי לאתר את הבעיות.
הרבע השלישי בא להראות שזהו המוצר שהלקוח צריך (למרות שכביכול יש לנו כבר תוצאות של שני הרבעים הראשונים). הוא בודק אם המוצר עונה לדרישות ועומד בתחרות. כאן אנו מדמים משתמשים אמיתיים.
אלו בדיקות ידניות בלבד.
אלו בדיקות UAT, אקספלורטורי ויוזביליטי.
הרבע הרביעי הוא טכנולוגי שגם מבקר את המוצר, למשל:
בדיקת ביצועים
עמידות (robustness)
Security
בחלק מהמקרים בדיקות אלה צריכות להיעשות לפני כל שאר הבדיקות.
וזה הצ'קליסט כפי שמופיע בספר:
- Are we using unit and component tests to help us find the right design for our application?
- Do we have an automated build process that runs our automated unit tests for quick feedback?
- Do our business-facing tests help us deliver a product that matches customers’ expectations?
- Are we capturing the right examples of desired system behavior? Do we need more? Are we basing our tests on these examples?
- Do we show prototypes of UIs and reports to the users before we start coding them? Can the users relate them to how the finished software will work?
- Do we budget enough time for exploratory testing? How do we tackle usability testing? Are we involving our customers enough?
- Do we consider technological requirements such as performance and security early enough in the development cycle? Do we have the right tools to do “ility” testing?
אין תגובות:
הוסף רשומת תגובה