לקבל או לא לקבל גרסה פגומה לבדיקות?

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

לכאורה מצב ברור של "No Go". אבל נשאלת השאלה מה טוב יותר למוצר, או לחברה: לקבל בכל זאת את המוצר כפי שהוא או לחכות?

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

מה בעד קבלת הגרסה?

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

מה נגד (בהתאמה לסעיפים למעלה)?

1. הבודקים עלולים ל"הישרף". אם המוצר מלא בבעיות או נופל כל 10 דקות, הבודקים יחושו שהם עובדים לחינם, והמוצר עלול באופן טבעי להימאס עליהם.
2. הכרת המוצר מוטלת בספק כיוון שאולי משהו עובד בדרך X כיוון שיש בעייה Y. אם חושבים ש-Y זה בסדר הבודקים יוסיפו TC שגויים וכו'.
3. נניח שהפיתוח מודע ל70% מהבעיות, ומה-30% הנותרים יש באגים שהם קריטיים וכאלה שלא. מה שיקרה הוא שהתהליך יעצר עד שיפתרו נניח 70% מהבעיות הידועות (עם השאר אפשר לחיות). אז בשלב ה-Unit tests או ה-Sanity יתגלו הבאגים הקריטיים ואז הגרסה תחזור לפיתוח. שום זמן לא בוזבז. העניין היחידי הוא שבמקום לפתור בעיות מינוריות יחסית הפיתוח היה פותר בעיות קריטיות יותר.
4. זה נכון, למרות שכבר די ברור שיש בעייה רצינית (מוצר כה גרוע שהבדיקות סרבו לקבל).

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

אני חושב מתוך ניסיוני שהתשת צוות הבדיקה במוצר גרוע היא זריקת מוות לאיכות המוצר. אני מאמין שאם אנו מקבלים מוצר סביר, שהבדיקות "רצות" ומידי פעם מתגלה באג, קל לנו בהרבה יותר למצוא את הבאגים הפחות קלים למציאה (אבל לעיתים קריטיים) ע"י exploratory testing שאנו עושים מעבר ל-TC באופן טבעי במוצר חדש או בפיצ'רים חדשים. במוצר בעייתי אנו לא ממש מגיעים לזה. בנוסף מכל הבלבול יהיה קשה לדעת איזו בעייה דווחה ואיזו לא ומה נסגר (אני יודע שחלק מזה לפחות אמור להיות מתועד אבל במצב כזה זה לא תמיד כך). יהיה קשה לראות דברים ברורים אחרי עשרות סבבים "עקרים", והבודקים יפתחו אנטגוניזם למוצר.

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

כמו תמיד יש מקום לשיקול. אם יש אפליקציית שרת-לקוח שהשרת מוכן וניתן לבדוק אותו כשלעצמו ואילו ה-client אינו מוכן - ניתן לקחת את השרת. אבל ככלל אני ממליץ בחום לא לקבל.

מה כן אפשר לעשות?

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