הצורך*: באג'ייל כל קבוצת פיתוח בנוייה בצורה מולטידיסציפלינרית (מפתחים בשפות ותחומים שונים, בודקים ועוד) והיא אמורה להיות די אוטונומית. כלומר אם יש קשר לחלק אחר של המוצר שאינו מוכן עדיין, בונים סימולטורים ובודקים בעזרתם כך שקבוצה אחת לא תהיה תלויה בלוחות זמנים של קבוצה אחרת.
הבעיה היא שבסוף נותנים מוצר מוגמר, או סט של מוצרים שקשורים ביניהם, שאמורים לעבוד היטב ביחד ותכלס לא נבדקו ביחד מספיק. מבחינה טכנית ישנו שלב של אינטגרציה (אבל גם זה עלול להיות מוגבל ולוודא רק שהתקשורת בין שתי הקומפוננטות / מערכות עובדת ולא מה קורה בהמשך). אבל מה קורה מבחינת הלקוח? האם הוא מקבל מהמערכת את מה שהוא צריך? בווטרפול היו קבוצות בדיקה חיצוניות שראו בד"כ את המוצר כשלם, אך לא עוד.
בעיני בעיה זו מתקשרת להבחנה בין ולידציה לוריפיקציה. ולידציה אומרת - האם בנינו את המוצר הנכון (אל מול הלקוח) לעומת וריפיקציה - האם אנו בונים את המוצר בצורה נכונה. בספרות המקצועית הולידציה היא ללא הרצת המוצר וקורת בשלב התכנון. בעיני צריך לעשות אותה גם עם המוצר, וזה הרעיון של משחק הקץ (תרגום השראתי שלי ל-endgame**): לבדוק שהלקוח מקבל את מה שהוא רוצה.
המונח Endgame בהקשר לבדיקות תוכנה באג'ייל מופיע בספר Agile Testing של Lisa Crispin ו-Janet Gregory בעמ' 456 ואינו ברור כלל. למרות שהנושא הזה חשוב הוא מוזכר בצורה שטחית למדי וזה עלול לגרום לבלבול. המונח עצמו, משחק הקץ, נראה רחב מידי (בדיקות פונקציונליות ושאינן כאלה כולל בדיקות עומסים גם בדיקות אוטומאטיות, גם דאטה בייס ועוד. קשה לי למשל לבדוק באותו זמן ב-100% יעילות גם בדיקה פונקציונלית וגם להבין אם זה מה שהלקוח רצה). ואכן בפועל אני מכיר מקום מסויים שאכן מנסה להשיג יותר מידי ולעיתים מאוחר מידי ממשחקי הקץ. מה עם וולידציה? דווקא זה לא מוזכר אבל נראה שזה בדיוק העניין.
מלבד העובדה שהרבה מידי תלוי במשחק הקץ לפי ההגדרה הזו, בדיקה של צוותים שונים באותו זמן נראה לי פשוט מתכון לאסון, ולו רק בשל ההפרעות שהצוותים השונים עלולים לגרום זה לזה (החבר'ה של הדאטה בייס סוגרים אותו לרגע ואז הבדיקה האוטומאטית נכשלת, למשל). עקב כך אני ממליץ לעשות בדיקות אינטגרציה וכל בדיקה אפשרית אחרת ברגע שאפשר ובמחשבת תחילה, וכך לצמצם את הסיכונים ככל האפשר ולא לדחות לסוף. לאחר מכן להגדיר במדויק את משחק הקץ - בדיקות שאכן חייבת להיעשות, מטרות וכד'. ולבסוף לתאם לוחות זמנים אופטימליים.
משחק הקץ, כפי שאני רואה אותו, אינו בא לומר שאין צורך לערוך בדיקות נוספות על המוצר הגמור: עומסים, אינטגרציות, ביצועים, סקיוריטי, ריקברי, אמינות וכד'. אלא שאלו בדיקות שתמיד עשינו ווטרפול או לא. לעומת זאת משחק הקץ במתכונת זו זה דבר חדש ועליו אני רוצה לשים כאן דגש.
אגב זה דבר חדש כיוון שבווטרפול היה צוות בדיקות אחד בד"כ שראה את התמונה המלאה ולא בודקים בצוותים סגורים שרואים רק את מה שהם עושים.
Endgame:
להלן הגדרות ברורות יותר של משחק הקץ הנובעות מניסיון רב שנים שלי בנושא.
המטרה של משחק הקץ:
לבדוק את המערכת E2E מנקודת המבט של המשתמש. הבדיקות יוודאו המשכיות בשימוש בין קומפננטות ומוצרים שפותחו על-ידי צוותים שונים, המשכיות ב-UX, זמני תגובה הגיוניים, התאמה של פיצ'רים חדשים לקיימים. הם יגלו שהערך ללקוח אכן התקבל כרעיון ולפי מה שאנשי המוצר הגדירו, את הכריזמה של המוצר.
הבדיקות ייוודאו דברים שקשה לפעמים לחשוב עליהם בצוותים - flows מסויימים, דרכי שימוש שלקוח עשוי לבחור בהן. חשוב להדגיש שהרעין אינו לבדוק נניח את כל אפשרויות הקונפיגורציה גם אם הן בשליטת המשתמש אלא flows.
גם באגים פונקציונליים יתגלו למשל כאלה שהאינטגרציה בצוותים שהיא נקודתית תפספס (ערך X עובד מקומפוננטה א' לקומפוננטה ב' כראוי, אבל האם X הוא הערך הנכון ומה קורה איתו לאורך הזרימה שלו במערכת?).
למשל הנה באג אמתי של משחק קץ: פגיעה ממש לא צפויה בהתנהגות דפדפן (איבוד היכולת של הרצת סרטי פלאש) אחרי התקנת תוסף. באג אחר: כל קומפוננטה עבדה מצוין, אבל ב-flows שכל לקוח היה עורך המערכת הייתה מפסיקה לעבוד אחרי זמן מסוים.
עוד אחד: בצוותים תרגלו התקנה על התקנה של המוצר (שדרוג) מול גרסאות ישנות. בפועל לראשונה בפרודקשין הייתה התקנה על התקנה של אותה גרסה מסיבות שונות. צוות משחק הקץ שלי פספס את הבאג הזה, למרות שהוא קלאסי למשחק קץ - בדיקה בקונפיגורציה של לקוח.
נכון שלא אמורים למצוא באגים בשלב זה (ראו תנאי כניסה - הפיתוח הסתיים ,רוב הבדיקות כבר הסתיימו) וחלק מהבאגים שימצאו אולי יהיו קטנים (ענייני UI בעיקר). אבל מצד שני זו הבדיקה האחרונה לפני שחרור, האחרונה מנקודת מבטו של המשתמש, ויש כאן סיכוי למצוא גם באגים קריטיים כמו אלה שתיארתי.
עקרונות
מטרה:
לבדוק בדיקה אחרונה את המוצר קצה-לקצה, מנקודת המבט של הלקוח וכך לוודא ש:
1. המוצר אכן נותן ערך ללקוח (ברמת המוצר).
2. לבדוק שבשימוש הצפוי של הלקוח אין באגים שנובעים מכך שהמוצר נבנה ע"י קבוצות שונות וזאת ע"י ביצוע flows שמאפיינים לקוחות אמתיים.
מי יוזם את משחקי הקץ?
1. ארכיטקט הבדיקות.
2. ארכיטקט פיתוח.
3. בודקים או צוות האג'ייל עצמו.
4. כל בעל עניין.
תנאי כניסה למשחק הקץ:
1. יש יותר מצוות אחד שמפתח את אותו המוצר או מוצרים שונים המשיקים זה לזה.
2. יש פיצ'ר חדש ומורכב...
3. ...או פיצ'ר חדש שנמצא במוצר מורכב.
4. פיצ'ר שפותח לאורך זמן (וקצת שכחנו או שלא בדקנו מזמן את החלקים הראשונים שלו).
5. הפיצרים נבדקו בצוותים ועברו את ה-DoD.
6. הייתה אינטגרציה.
הכנות:
כמו כל אקספלורטורי, יש להכין את הבדיקות. זה כולל קריאה של המסמכים של המוצר ו/או שיחה עם הפרודקט, שיחה עם בודקים ומפתחים בצוותים, ארכיטקטים וכד' - אבל הכל מההיבט של הלקוח. שם הטבלה למשל לא מעניין אותך בכלל, כמו שינויי רג'יסטרי וכד'.
ייש לתכנן מראש מה בודקים - בהתאם לשינויים שהיו וניהול סיכונים - ולתת צ'רטרים לכל מי שבודק.
טכניקה:
1. אקספלורטורי טסטינג.
2. אוטומציה (אבל בתור כלי עזר להגיע למצבים מסוימים).
איפה עורכים את הבדיקות:
1. בסביבה הדומה לפרודקשין ככל הניתן (מכונות דומות לאלו בפרודקשין, בסיס נתונים של הלקוח אם אפשר ועוד).
2. רק בדיקות אלו יערכו באותו זמן.
מתי:
לקראת סוף הפרוייקט כשכל תכולת הפיתוח מוכנה (אם אפשר לפני בין פיצ'רים מסוימים - מה טוב, אבל עדיין כדאי לעבור על הכל בסוף).
מי עורך את משחק הקץ?
1. בודקים אבל כאלה שלא מתוך הצוותים שפיתחו את המוצר/ים. בודקים אלה עלולים - וזה יכל לקרות לכולנו - דווקא בגלל ההכרה הטובה שלהם את המוצר לאבד קצת את נקודת המבט של המשתמש (נניח ברור לבודק שקשה להוסף במקום מסויים אפשרות חזרה להתחלה כי טכנית זה מסובך). כן אפשר שתהיה זו למשל קבוצה ייעודית של בודקים.
2. בעלי עניין, אנשים ממגוון תפקידים ומקומות בחברה.
מי לא ולמה?
הבודקים בצוות, אלא אם הם באים לא במקום אחרים אלא כתוספת.
מה משחק הקץ אינו:
1. רגרסיות. נכון שעוברים על הפיצ'רים הישנים כמו על החדשים. אבל הדגש הוא על השימושיות הכללית של המערכת בכלל ובפרט עם השינויים האחרונים.
2. בדיקות סיסטם. כלומר סוג של, אבל בדיקות סיסטם יכולות למשל להיות אוטומטיות, לבדוק עומסים ועוד.
3. בדיקות אינטגרציה. אלו באות קודם ולא בהכרח בודקות מספיק או את כל המערכת.
מה עושים עם הבאגים?
רק הקריטיים מתוקנים בזמן משחק הקץ או אחריו.
מי מתקן? מי בודק?
הצוות שהקוד שלו יצר את הבאג עושה את שניהם. לא תמיד צריך לחזור על משחק הקץ אחרי התיקון (לפחות לא במלואו).
בעיות שעלולות לצוץ בפועל:
1. מהו ההיקף של הבדיקות? נניח שיש פיצ'ר מורכב עם הרבה אפשרויות. האם בודקים את כולן? כנראה שלא. מה עושים? יושבים ביחד עם בעלי העניין ומחליטים מה אמור להיות נפוץ יותר.
2. מה קורה אם לא מוצאים כלום? זה יכול לקרות במוצר בוגר שפותח ונבדק היטב. מוצאים שיטות חדשות לבדיקה – מתוך קריאת מאמרים, דמיון וכד'. שימוש מתמשך במוצר במחשב / בטלפון האישי. אולי במקרה זה לא צריך משחקי הקץ? אולי, אבל קחו בחשבון שלפעמים באג כאן יכול בקלות לגרום ל-rollback ולפגיעה קשה בצרכנים או באימון שלהם במוצר.
3. האם בודקים מכשירים שונים ו/או מערכות הפעלה? בודקים בד"כ מכשירים / מערכות הפעלה מובילים.
4. מה היחס לסיכונים? גם וגם. נבדוק איך שלדעתנו רוב המשתמשים ישתמשו וגם נעבור גם דרך נקודות מסוכנות יותר - אבל שוב, לא נחפור - את זה עשו בשלב קודם.
5. אם משהו חדש לחלוטין – איך יודעים מה המשתמש יעשה? הבעיה הקשה מכולם. דברו עם מנהל המוצר, נסו את שיטת הכובעים, תנו לכמה שיותר אנשים שאינם בודקים ואם אפשר קרובים למשתמש הקצה לבדוק, אם יש שיתוף פעולה של הלקוח - להזמין גם אותו.
משחק הקץ מזכיר לי נושא אחר בתחום פיתוח התוכנה. הרבה קבוצות עברו לאג'ייל, אבל לא השאירו סמכות מקצועית של בודק תוכנה שנמצא מחוץ לצוות בכדי לקדם את תחום הבדיקות בחברה. כתוצאה מכך אין לי ספק שבחלק מהמקומות איכות הבדיקות ירדה. אותו דבר לגבי זה - אני לא בטוח כמה מיישמים את עניין משחקי הקץ בחברות השונות, ומבחינתי הוא קריטי.
*כבר כתבתי על נושא חשוב זה בעבר. התירוץ שלי לחזור על זה זה כיוון שהוספתי למה שנכתב הרבה ניסיון מהשטח.
** המונח עצמו באנגלית הינו: The final stages of an extended process of negotiation. בשחמט: The final stages of a chess game after most of the pieces have been removed from the board.
אין תגובות:
הוסף רשומת תגובה