Probably the easiest thing would be to be the friendly neighborhood bully and pick up on some of the many mistakes there are in the post that indicates that the author either has no understanding of what exploratory tests are, or he is using a very private and skewed definition of ET (some candidates are the claim that there is no test planning in ET, the axiom "good tests have well defined and agreed upon pass criteria in advance" or my favorite: "[...]some Exploratory gurus assiduously disdain requirements; so they’re very unlikely to get involved with intermediate development deliverables prior to executable code"), but I prefer to avoid public ranting and patronizing people I don't know, so instead, I'd rather say why I don't think in terms of test cases and why I usually avoid this language.
I'll start with the obvious truth - some of what I do can be described in test-cases language. While I'm "testing" (or "exploring", if you prefer this term) I'm doing a lot of checking that can be translated to test-cases language, as can some of my more vague observations (e.g. "this doesn't look comfortable") could sometimes be translated to a test case without stretching it (in fact, once a problem is spotted, defining a test case around it is usually easy). So, yes - if someone insists, I am "executing test-cases" and I'm doing it wrong in as many ways as shorthand writing is doing calligraphy wrong.
And that's, in short, is the reason I try to avoid using the language of "test cases" - It comes with a lot's of baggage. When I say "test case" I'm also saying "heavy predefined documents" and "step-by-step instructions", which is not what I'm trying to convey. When I talk about my testing, I focus on getting my team to agree on what we should test, on what risks do we want to address and I rely on my skills. During my work I will use checklists, I will review any source of information I have (and get those I need) and have my team review both my intentions and my work. Heck, we've recently spent a full week reformatting data into excel sheet just so that we could deal with an unusually large testing problem. And yet - I don't say "test cases".
Another matter I want to address is the odd dichotomy created between "exploratory testing" and writing a test case. When you think about it closely, it is pretty much the same thing. When I spent some time writing down very detailed test cases, I could never do it without actually having the software and performing it at the same time, and I have yet to meet a tester who wrote a test plan without "winging it". Sure, some of us improvise magnificently using all sorts of techniques - from equivalence partitioning to combinatorial testing to personas and use cases - but all of that charade is simply masking the fact that we apply our experience, skills and gut feelings to choosing the data and the techniques that will be applied (no, I'm not saying those techniques are a sophisticated fraud, they are valuable, very much so sometimes, but the skilled tester will know when to apply each technique or tool and when not to).
I want to ask you to think of the following question: what would be the result of exploratory testing a requirements document?
...
...
...
...
Done thinking? have your answer? Great. Unless, of course, your answer was "exploratory testing must have a working product to act upon", which is simply wrong. But in any other case, great.
My answer is - test plan. When I test a requirements document (for those who use the ISTQB vocabulary, please recall that a review is a form of a static test), I come up with a model of how the software is supposed to function, with questions pointing at gaps in this model, or inconsistencies in the requirements, I compose a list of risks that we might want to put some safeguards against (some of them may be "test this area once it's done and look for that sort of glitches") and I add my knowledge and experience back to the team. I was definitely testing, and since I was learning about the product during this activity, I would say it falls under the definition of "exploratory" part as well (Also, if we avoid quoting anonymous "gurus" and stick with quotes we can trace, I tend to agree with Bach & Bolton's definition, according to which all testing is exploratory).
So, if we accept that writing a test plan is, in fact, an act of exploratory testing, why do we claim that executing the results is any different? And why do we insist on separating test execution from test planning? Sure, there are cases where we might want to plan more beforehand - to make sure we don't forget or to fight off some of the bias that we might have after testing the same thing for a while, but there are other cases where we might not want to do so. Relying on skilled testing allows us that freedom of doing what we think is right for our project. Which leads us back to why I don't like using the term "test case" - it just draws the focus from what's important.
---------------------------------------
מה יש לומר רנדל מונרו (ההוא מXKCD) ידע על מה הוא מדבר. יש מעט מאוד דברים שגורמים למוטיבציה כמו לראות מישהו טועה באינטרנט. הפעם, רפרפתי דרך רשימת הקריאה שלי כשהגעתי לבלוג של פרקטיטסט ושם היה המאמר עם הכותרת ההו-כה-מבריקה "You Don’t Have Test Cases, Think Again". נו, מילא. בדרך כלל אני מוצא שם פוסטים מרתקים, אז אולי יש פה ניסיון לתפוס את תשומת הלב כדי לגרום לי לחשוב. כמובן, כיוון שקראתי דרך הפלאפון, דילגתי בקלילות מעל האזהרה שהייתה כתובה באותיות של קידוש לבנה בראש העמוד והמשכתי לקרוא - מצפה לרעיון מעניין. ובכן, מהר מאוד הבנתי שמעניין זה לא יהיה, כי כל המאמר מבוסס על חוסר הבנה משווע של (הדרך בה אני חושב שצריך להבין) בדיקות חוקרות, ואפילו של בדיקות בכלל. ולכן (ובדחיפה קטנה מצד יואל) - הפוסט הזה.
ככל הנראה, הדבר הקל ביותר לעשות יהיה להיטפל למגוון הרחב למדי של טעויות והצהרות יומרניות שאפשר למצוא בפוסט ההוא (כמו הטענה שאין תכנון בבדיקות חוקרות, או ההכרזה שכמה "גורו"אים של בדיקות חקר אלרגיים לדרישות ולכן מעורבים רק ברגע בו יש תוכנה פועלת שאפשר "לחקור"), אבל אני משתדל להשמיץ אנשים שאני לא מכיר רק בקרב חוג חברי הקרובים ומשתדל להיות יחסית מנומס בפומבי, כך שאני רוצה להסתכל על הנושא מזווית אחרת - למה אני לא מתלהב מהשימוש ב"מקרה בדיקה" (המונח העברי כאן בעיקר מטעמי נוחות הכתיבה, בעולם האמיתי אני בדרך כלל נתקל באנשים שאומרים "טסט קייס").
קודם כל, הכרה קטנה במציאות כפי שהיא - חלק מהפעילות שלי, ובמיוחד חלק מהפעילות שלי בזמן שאני בודק (ולא, נניח, מכלה את זמני בישיבות, או עובד על פרוייקט צדדי), אפשר לתאר בשפה של מקרי בדיקה. בזמן שאני "בודק" (או "חוקר") את המוצר, אני מבצע לא מעט מבדקים שאפשר לתרגם, פחות או יותר, לשפה הזו. לכן, הטענה הבסיסית של הפוסט ההוא היא פלוס מינוס נכונה - בודקי תוכנה ממשיכים לבדוק תוכנה, והפעילות הבסיסית אליה הובילו מקרי-בדיקה עדיין מתרחשת. אז כן, בהחלט אפשר לומר שאני מבצע מקרי-בדיקה, ושאני עושה את זה לא נכון. לא נכון באותו אופן בו כתב קצרנות הוא ביצוע די עלוב של קליגרפיה.
וזו, בקצרה, הסיבה בגללה אני לא אוהב את המונח הזה - הוא מגיע עם הרבה יותר מדי מטען. אם אני אומר שאני מבצע "מקרי בדיקה", מה שמשתמע בתוך זה הוא גם כתיבה מראש של ערימת מסמכים גבוהה למדי וגם מתכון של צעד-אחד-צעד שלכאורה אמור להיות שם, וזה בהחלט לא מה שאני מנסה לומר. כשאני מדבר על בדיקות תוכנה, אני מתמקד בלגרום לצוות להסכים על הכיוון ועל הכיסוי שאנחנו מנסים להשיג,להסכים על הדברים שמדאיגים אותנו יותר ואלו שפחות. כשאני מדבר על בדיקות, אחת ההנחות עליהן אני מתבסס היא שמדובר בעבודה לה נדרשת מיומנות.
במהלך העבודה שלי אני בהחלט עשוי לכתוב לעצמי רשימות, אני סוקר את כל מקורות המידע הרלוונטיים שיש (או שאני צריך ומשיג) ואני מעמיד לסקירה גם את הכוונות שלי (מראש) וגם את מה שעשיתי (בדיעבד), רבאק - בילינו למעלה משבוע בהעברה של נתונים לקבצי אקסל רק כדי שנוכל להתמודד עם משימה אחת שהייתה גדולה במיוחד, ולמרות זאת, אני לא משתמש במונח "מקרי בדיקה".
אם אנחנו כבר כאן, אני רוצה להתייחס לעוד נקודה שהפריעה לי בפוסט ההוא, והיא החלוקה המשונה בין "בדיקות חוקרות" לבדיקות מתוסרטות. כשעוצרים לחשוב על זה מקרוב, זה פחות או יותר אותו הדבר. בעבר, כשהקדשתי הרבה מאוד זמן לכתיבה של תסריטי בדיקה מפורטים, הדרך היחידה בה יכולתי לעשות את זה הייתה על ידי ביצוע של התסריט במקביל לכתיבה (וכניסיתי לכתוב במנותק מהתוכנה, הייתי צריך לשכתב הכל בהרצה הראשונה). מצד שני, מעולם לא פגשתי בודק תוכנה שלא כתב את תוכנית הבדיקות תוך כדי אלתור. נכון, חלק מאיתנו מאלתרים ממש נהדר עם כלים מרשימים כמו מחלקות שקילות, בדיקות קומבינטוריות, פרסונות או מקרי-שימוש (use cases, בלע"ז), אבל בסופו של יום, הבודק שכותב את תוכנית הבדיקות הוא זה שבוחר באיזה כלי להשתמש ואילו נתונים מוזנים לתוך כל אותם כלים (כמובן, אני לא טוען שהכלים האלה חסרי תועלת - להיפך, יש בהם תועלת רבה - אבל בסופו של יום, הבודק המיומן ידע מתי נכון להשתמש באיזה כלי ומתי לא).
אני רוצה להציג את השאלה הבאה: כיצד יראו התוצאות של בדיקות חוקרות של מסמך דרישות?
קחו רגע לחשוב על זה.
...
...
...
...
חשבתם? מצויין. כל מי שענה "בדיקות חוקרות אפשר לעשות רק על תוכנה קיימת שאפשר להפעיל ולחקור", שילך להתבייש בפינה. כל היתר - מצויין.
התשובה שלי לזה היא "זה נראה כמו תוכנית בדיקות". כשאני בודק מסמך (ולאלה שמחבבים את המינוח שמשמש את ISTQB, תזכורת - סקירה של מסמך היא חלק ממה שאנחנו מכנים בשם "בדיקות סטטיות"), אני מייצר מודל של איך התוכנה אמורה לפעול, אני אוסף שאלות שמצביעות על פערים במודל, או על חוסר עקביות בדרישות. אני מחפש סיכונים שאולי נרצה להתייחס אליהם ולהציב כמה מנגנוני הגנה כדי להקטין את הנזק מהם (ולפעמים מנגנון ההגנה הזה הוא "נבדוק את התוכנה כשתהיה מוכנה ונחפש תקלות מסוג מסויים ברכיב הזה), ואז אני מוסיף את הידע שאספתי בחזרה לצוות כדי שנוכל להתייחס אליו. בקיצור, איך שלא מסתכלים על זה, ביצעתי כאן "בדיקות". אם נשים לב שבמהלך התהליך הזה גם למדתי על המוצר והתאמתי את המודלים שלי אליו תוך כדי שההבנה שלי גדלה, אני חושב שאנחנו מכסים גם את החלק של "חוקרות" (ואם לא, אפשר לצטט אנשים אמיתיים ולא להעמיד פנים שיש "גורו"ים אלמוניים, כי אני מסכים למדי עם ההגדרה של באך ובולטון לפיה "כל הבדיקות הן בדיקות חוקרות" ).
בקיצור, אם אנחנו מקבלים את זה שכתיבת תוכנית בדיקות היא ביצוע בדיקות חוקרות, איך אפשר לבסס את הטענה שביצוע של הבדיקות האלה הוא סוג אחר של בדיקות? ולמה להתעקש על הפרדה של תכנון הבדיקות וביצוען בפועל? בטח, יש מקרים בהם עדיף לנו לכתוב כל מיני דברים מראש - אם יש דברים שחשוב לנו לא לשכוח, או אם אנחנו רוצים להתמודד עם מגוון רחב של הטיות שיש לנו תוך כדי התעסקות בתוכנה - אבל יש גם מקרים בהם כתיבה מראש היא בזבוז זמן ותו לא. ההסתמכות על מיומנותם של בודקי התוכנה מאפשרת לנו את החירות לבחור במה שנכון עבור המצב בו אנחנו נמצאים, ולכן אני מעדיף שלא להשתמש במונחים שמסיטים את תשומת הלב מהעובדה החשובה הזו.
