יום חמישי, 18 באוקטובר 2018

בדיקות סיוריות (אקספלורטורי): מכתב אישי לסקפטי האחרון

שלום מר סקפטי, אני יודע שמאוד אכפת לך ממה שאתה עושה וחשובה לך איכות המוצר. אתה מכיר את המונח "אקספלורטורי טסטינג", אתה מבין את היתרונות, אבל קשה לך לוותר על הרעיון שסקריפטד יותר מובנה ולכן ימצא יותר באגים. הרבה מאוד כבר נכתב, גם על-ידי, על בדיקות סיוריות (או אקספלורטורי טסטינג). אבל עד היום אנשים משתמשים עדיין בבדיקות "סקריפטד" מהסיבות הלא נכונות. אני חושב שעיקר הדאגה נובע מרמת הכיסוי. האינטואיציה שלנו אומרת שעבודה מסודרת תניב יותר פירות, ומה יותר מסודר מרצף בדיקות שנכתב מראש, עבר ביקורות והוסמך להיות מסמך הבדיקות הרשמי? ואילו בדיקות סיוריות אינן הולכות בקו לינארי אלא לפי שיקולו של הבודק באותו רגע של בדיקה. ומה יקרה אם הדרך שלו לא תכסה דברים חשובים כי האינטואיציה שלו תוביל למקומות אחרים?
Designed by Kues
ריכזתי למטה בשבילך כמה שאלות ותשובות בנושא. אבל לפני זה, ברצוני להציג לך מחקר אקדמי שבדק את הנושא. בעבודה שנעשתה באוניברסיטה של הלסינקי, פינלנד, ושניתן למצוא אותה כאן, רצו לבדוק בדיוק את מה שדיברנו עליו, או במילים שלהם: "האם בודקים שמבצעים בדיקות ידניות פונקציונליות עם תסריטים מוכנים מראש מוצאים יותר באגים או באגים שונים בהשוואה לבודקים ללא תסריטי בדיקה?" בניסוי סטודנטים חולקו בצורה מקרית לשני קבוצות. לשתי הקבוצות היה אותו זמן לתכנן את הבדיקות. הסטודנטים ידעו שתוצאות טובות מצידם יעלו להם את הציון. הנה תמצית התוצאה:
This paper makes four contributions. First, we identify a lack of research on manual test execution from other than the test case design point of view. It is obvious that focusing only on test case design techniques do not cover many important aspects that affect manual testing. Second, our data showed no benefit in terms of defect detection efficiency of using predesigned test cases in comparison to an exploratory testing approach. Third, there appear to be no big differences in the detected defect types, severities, and in detection difficulty. Fourth, our data indicates that test case based testing produces more false defect reports.
עוד שאלות? בבקשה: ש. אם אני בודק שדה טקסט. מה כבר יכול להיות סיורי כאן? ת. דווקא כאן יש יתרון ברור לסיורי: למשל special characters. אם נכתוב בדיוק מהם, זה מה שייבדק לנצח. אם ניתן לדמיון הבודק, כל פעם יהיה משהו אחר, וכך יש סיכוי למצוא באג חמקני, אם קיים.
ש. רגרסיות זה קלאסי לסקריפטד, בטח שלאוטומציה. ת. נכון, יש הרבה בדיקות (checks) שעדיף שיהיו אוטומטיות. אבל בדיקות אלה אינן עושות הערכה על איכות, אלא רק שפעולה או רצף קבוע של פעולות גורם לתוצאה דטרמיניסטית כזו או אחרת, ולא - זה באג. זה טוב שיהיו בדיקות אוטומטיות, אבל זה לא מספיק. צריך עדיין ייצור אנושי שיעבור על התוכנה. נראה שהתמהיל הנכון הוא הרבה בדיקות אוטומטיות וגם בדיקות סיוריות. אם יש לכם רגרסיות ללא כיסוי אוטומטי אופטימלי - אין בעיה, אתם יכולים להריץ אותם. אבל לא יהיה מעניין יותר לבודקים לקחת את המסמכים, לעקוב בקריאה אחרי הצעדים אבל לעשות אותם קצת שונה?
ש. אין לנו אוטומציה. האם מספיק להריץ בדיקות סיוריות בלבד? ת. תלוי במוצר. למשל תוכנה רפואית עשויה לדרוש תיעוד של כמה שנים אחורה של תוצאות הבדיקות. אבל מבחינת העומק של הבדיקות ניתן להגיע לאותו עומק וכיסוי כמו בדיקות סקריפטד.
ש. אבל ידע רב על המוצר נמצא במסמכי הבדיקות. ת. נכון, פעמים רבות רק שם אפשר לדעת איך משהו עובד. אבל זה לא באמת המקום לשמור מידע מוצרי או אפילו טכני. שמרו את המידע הזה, אבל בנפרד בוויקי של החברה, קונפלואנס או כל מקום זמין אחר.
ש. איך אני יודע שהכיסוי של בדיקות המעודדות "התפזרות" (מסוימת) אכן כיסו את כל מה שאמורים לכסות? בסקריפטד אני יודע בדיוק מה נעשה וכך מה כוסה. בסיוריות בקלות אפשר לפספס משהו. ת. בדיקות סיוריות מצריכות הכנה לא פחותה מבדיקות סקריפטד. הבודק אמור לדעת מראש אילו חלקים ייבדקו. כן, מותר לו להתפזר, אך עדיין עליו להישאר במסגרת הצ'רטר. בנוסף, אפשר לערוך בדיקות סיוריות "מחמירות" יותר שנקראות SBTM. ולבסוף, בספרו של וויטאקר על בדיקות סיוריות, הוא מראה שתכנון נכון של הבדיקות וביצוע מגוון מתוכנן שלהן יביא לכיסוי מלא.
ש. חוץ מזמן כתיבת הבדיקות, מה אנו מרוויחים מביצוע בדיקות סיוריות? ת. גם הזמן זה חשוב, אבל יש לא מעט דברים נוספים. • זה יותר מעניין לבצע בדיקות אלה. הבודק אינו מרגיש כמו אוטומט אלא כאדם חושב, יצירתי. • הבדיקות מגיעות לנקודות שלא כתובות בתסריטים כיוון שאי אפשר לחשוב מראש על כל מיני מקומות שניתן לחשוב עליהם בזמן ההרצה. • זה הרבה יותר דומה למה שהלקוח יעשה. • אפשר לקבל הרגשה טובה יותר על איכות הגרסה (בעיקר כשאין באגים קריטיים שקופצים מיד). • הרבה פעמים הפידבק יהיה מהיר הרבה יותר בבדיקות סיוריות.
ש. מה קורה אם כל או חלק גדול מהבודקים הם חדשים בתחום? או בחברה? ת. שאלה טובה. בודק בעל ידע אך לא בעל ניסיון ימצא באגים, אבל לא במידה כזו שמתקרבת לבודק מיומן. אם כל הבודקים מסיבה כזו או אחרת כאלה, אין לי תשובה טובה לתת. אם היו מסמכים מפורטים היה מצבם הרבה יותר טוב. אבל כמה פעמים זה קורה? לעומת זאת אם יש גם בודקים מיומנים הם יכולים לשבת עם החדשים לפני כל הרצה של בדיקות, לעבור על המסמך ולתת טיפים. אם כולם חדשים בחברה אבל בודקים מיומנים אז אולי הם לא יתחילו בתפוקה מלאה, אבל הם יכולים לשבת עם הפיתוח לפני כל הרצה להסבר טכני. לסיכום, אני מאמין אתה יכול לעבור לבדיקות סיוריות. אם אתה לא בטוח - עשה ניסוי. בדוק בשתי הדרכים.
אני עשיתי את הניסוי הזה, ולי אין ספק שאקספלורטורי עדיף.
יום טוב, דורון

אין תגובות:

הוסף רשומת תגובה

רשומות פופולריות