הספר הזה, Agile Testing: A Practical Guide for Testers and Agile Teams , יכול להיחשב כבסיס הידע של בדיקות התוכנה. נכון, קשור לאג'ייל, אבל גם מי שלא עובד באג'ייל ימצא הרבה דברים שיכולים לעזור לו, ברמה כזו ששווה גם לו (או לה) לקרוא את הספר.
התוכן של הספר הוא עצום: הסברים על האג'ייל בכלל ובעיקר בהקשר של הבדיקות, סוגי הבדיקות, מערכת היחסים בין הבודקים למפתחים, תכנון בדיקות והאם להשתמש ב-Test Plan או לא, ועוד הרבה. הספר עבה, ובכל פרק אפשר למצוא כמות נכבדה של עצות מעולות. האמת היא שלפעמים רק בזכות הניסיון הארוך שלי בתחום הבדיקות אני יכול להבין עד כמה טובות חלק מהתובנות שהמחברות נותנות (כיוון שלי לקח זמן ולפעמים טעויות בכדי להגיע אליהן). לדעתי הספר הוא כמעט חובה, אבל חשוב לתאם ציפיות :)
דבר אחד חשוב לומר, שנרמז לי בשיחה עם ג'יימס באך והבנתי שזה נכון: למרות שמו, הספר לא מדבר על ממש על בדיקות בפועל, כמו ספרים קודמים שסקרתי. הוא מדבר יותר על אסטרטגיה של בדיקות: תהליכים, יחסים, איך לאסוף מידע, איך לייעל ועוד. הוא לא מדבר על שיטת בדיקות כמו למשל Touring Exploratory Testing, למסביר על קפיצה מפיצ'ר לפיצ'ר, בדיקה של פרמטרים לא דיפולטיביים ועוד.
חיסרון שני הוא דבר שלי זה צורם, והוא קשר ליחסי לאג'ייל בכלל: לפעמים נדמה שהן מדברות על אנשים מושלמים בתוך הצוות. כן, יש מקום לטעויות, אבל נדמה שהאנשים בספר כולם מחויבים במאה אחוז, פרו-אקטיבים, מוכנים לשינויים וכד'. בפועל, כולנו לא מושלמים (חוץ מאשתי, כמובן), ותורה סדורה אמורה להתייחס לזה. בהקצנה, זו אחת הבעיות של הקומוניזם: לא, לא כולנו נולדנו שווים.
אני מביא דוגמא למשהו שמופיע בספר, בכדי קצת ל"קבל תחושה" ממנו.
לטענת הכותבות, אם נבין את המטרות של הבדיקות, נבין אילו סוגי בדיקות אנו צריכים.
בהתאם לזאת הסופרות מחלקות את הבדיקות לארבעה רבעים:
ביקורת ספר: Agile Testing וסוגי הבדיקות בסביבה אג'יליתביקורת ספר: 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?
אין תגובות:
הוסף רשומת תגובה