Over the course of the past week, I noticed a name for something several Exploratory testers already do. I crossed the idea first while reviewing one of the chapters in an upcoming book on how to reduce the cost of testing. The chapter was written by Michael Kelly, and discussed Session-based Test Management or “Managing Testing based on sessions” as Carsten Feilberg recently pointed out at EuroSTAR.
The idea is simple. Challenged by Michael Bolton, I came up with the description, that Inspectional Testing is like scratching the ice from the windshield of your car in the winter. If you have lots of time, you scratch all windows free completely. If you don’t have enough time, you know that you should scratch everything free before starting to drive, but you can also select to scratch just some of the ice, so that you see enough to start driving. You risk a car crash at that time, but over time the ice will melt while driving. So, depending on the time you feel comfortable with to take for your testing activities, you start testing just enough. After the first charter, you reflect on your first time-boxed test session, and come up with additional tests as you see fit. You see clearer than before at this point in time, but you may want to dive into some topics in more depth. This is like letting the ice melt while you drive in your car.
Inspectional Testing is motivated based upon a book I am currently reading called “How to read a book”. In it, the authors describe different strategies for reading a book. One of it is called Inspectional reading, where you try to find out enough information about a book in a given amount of time. You try to get an overview of the book, and make an informed about whether or not to dive deeper into it. The same goes for Inspectional Testing or scratching your car-windows. Sometimes you need to make the decision to deal with less in depth knowledge in order to make progress. You try to make an informed decision about the product you are testing. You try to test in order to build your first model about the application. Based on that first model you make an informed decision about the scope and priority of your next charters and missions within the product.
The underlying idea though is to use as much time as you feel comfortable to do so. For example in a typical Weekend Testing session of one hour with a broad mission, I would dive in and do just Inspectional Testing to get a first view of the application. The same goes for a broad mission within a Testing Dojo. On the other hand, if I was asked to test something for my job, I would take an Inspectional Testing session, in order to get a first understanding about the application. Based upon that knowledge and model, I can build new charters for areas of the product that I am particularly interested in after dealing with the product for maybe 90 minutes. At that point I got a first understanding about the product, and can set aside new charters based upon the knowledge that I got.
The idea is not new, as we used it for example when being introduced to a project which was already two months late. A colleague and I had three weeks left. During the first week we worked on bugfixes and retesting mainly. By doing so we created a first model of the underlying business rules, and got a great understanding about the thing we were building. After the first week, we had enough information to bring in test automation for the repetitious tests that we were running. By then we were able to automate the most relevant tests within two weeks based upon our good knowledge of the application. During the first week we used Inspectional Testing to get an understanding. During the last two weeks we were able to use that understanding to make the right decisions while continuing to test.
I would be pleased to hear from other testers how they do Inspectional Testing, and whether there are other names out there. Also feel free to leave a better explanation.