הבדיקות מול סביבות העבודה השונות: פיתוח, בדיקות ולקוח

בעיקרון יש שלש סביבות של עבודה הרלוונטיות לצוות הבדיקה:

סביבת הפיתוח;
סביבת הבדיקות (ידוע כ-staging);
סביבת לקוח (ידוע כ-production).


סביבת הפיתוחסביבת הפיתוח פעמים רבות שונה משמעותית מסביבת הלקוח (תצורה שונה, למשל כמה שרתים ו-clients באותו מחשב).
בנוסף זוהי סביבה לא יציבה כיוון שהיא כוללת גם חלקים שונים של קוד שנמצא באותו זמן בפיתוח ואינו סגור ואינו מתקשר עם מודולים אחרים. ואפילו אם היא יציבה, ייתכנו שינויי קוד רבים אחרים – חלקם מהותיים – בנקודות שונות בתהליך הפיתוח.
השאלה היא האם לערוך בדיקות בסביבה זו? מצד אחד הרי ברור מלכתחילה שהבדיקות כאן לא "יתפסו מים" ויהיה צורך לערוך אותן שוב בסביבה איכותית יותר, מה שאולי הופך אותן למיותרות ומעמיס על צוות הבדיקות לא רק בעבודה נוספת אלא בשחיקה. בנוסף זה יפריע לצוות הפיתוח בשאלות כמו: "למה השמירה לא עובדת? אתה עובד על זה כרגע?" וחבל.
מצד שני יש יתרונות בעבודה על סביבה זו, בעיקר כיוון שמציאת באגים כשזה בחדר הפיתוח זול יותר:
צמצום זמן בחיסכון בהעלאת גרסאות לסביבת הבדיקות. ברור שיהיו העלאות כאלה, אך פחות, וזה בתורו יחסוך זמן של קימפול (אם יש צורך בכך), אריזה וכד'.
חסכון בזמן בדיקות sanity ע"י הבדיקות.
מציאת הבעיה ותיקונה מהיר יותר על ידי המפתח שרק סיים פחות-או-יותר לעבוד על הנושא.
מציאת באג בשלב זה עשוי למנוע "פיתוח" של באג אחר שינבע מתוך הבעיה הזו. נניח מפתח א' לוקח פרמטר מסוים ומגדיר אותו כ-int שזו הגדרה שגויה במקרה הזה, ומפתח ב' מוסיף פרמטר מאותה משפחה גם כ-int על סמך קודמו.

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

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

בסופו של דבר לדעתי זה צריך להיות תלוי במנהל הבדיקות תוך התייעצות עם הפיתוח.

סביבת הבדיקותבין אם היו סבבי בדיקות בסביבת הפיתוח או בין אם לאו, יש לעבור סב מסודר של בדיקות בסביבת ה-staging. ייתכן שיהיו בעיות שכלל לא נתקלו בהן בסביבת הפיתוח ולא רק בשל הקונפיגורציה השונה. בסביבה זו מצופה רמת בשלות מצד המוצר (בין עם עזרנו לפיתוח ובין אם נתנו להם מסמך שאומר: X, Y ו-Z צריכים לעבוד אחרת אין לנו מה לעשות עם המוצר). כאן עושים סבב בעוד הפיתוח עסוק בתיקון הבאגים החדשים ושאריות של באגים קיימים אם יש. מידי פעם יש לעלות גרסה חדשה מסביבת הפיתוח לסביבת הבדיקות עם תיקונים. אם אכן המוצר בשל אין צורך בהעלאה יומית בכדי לחסוך את האריזה וה-sanity, שאותו יש לקיים על כל עלייה של build חדש.
אין חובה לבדוק את כל הבאגים שנסגרו בסביבת הפיתוח אלא את המשמעותיים. ההנחה היא שממילא תוכנית הבדיקה כוללת את כל התסריטים כולל אלו שיצרו את הבאג מלכתחילה, או שמדובר בבאג שיש רק סיכון נמוך שיחזור או שהשפעתו בטלה בשישים.
בדיקות קיט: בסוף תהליך הבדיקות יש לנקות את סביבת הבדיקות, לקחת את דיסק התקנת המוצר ולהתקין כמו כל לקוח לפי ההוראות ולוודא שה"דבר" עובד (כן, שוב sanity).

סביבת הלקוחאם יש לכם גישה לסביבת לקוח תמיד כדאי לעשות את הדברים הבאים:
לעבור על באגים עיקריים שתוקנו ולוודא שהן אכן פתורים.
לעשות sanity על המוצר כולו.