From a Test Case Follower to Becoming Context-Driven

Introduction? 

Cem Kaner coined the term “exploratory testing” more than 20 years ago. Since then, the practice which was publicly advocated by only a few people, has become a practice that many skilled testers have utilised. Yet, there are still many who have not gotten the chance to do skilled (exploratory) testing yet. Speaking for myself, I came to know about this about two years ago.

So what is Exploratory testing? 

Here are some of the definitions, including one that I do not fully agree with: 

An informal test design technique where the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests. ISTQB Glossary

Exploratory testing is a systematic approach for learning about the target of testing for all kinds of information, and has [its strengths] in enabling us to learn things we don't even know we don't know about [our] systems. - Maaret Pyhäjärvi [ebook] 

Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes: questioning, study, modeling, observation and inference, output checking, etc. - Rapid Software Testing 

A tester’s job on the project is to be the headlights of the project and notify the team of any challenges or risks that might affect the project’s goal to solve the problem at hand. We thus become the information providers to many of the stakeholders that matter. 

To find this information, we have to evaluate the product as best as we can through questioning assumptions, even the implicit ones and exploration. 

To explore we have to: question the product, play and experiment with the product. This is done more effectively when we make good use of heuristics, analysis techniques and models of the product from varying perspectives. I am quite surprised that the ISTQB calls exploratory testing an informal test design technique as this approach requires skill and deliberate practice to master. 

You may wonder why I included a definition about testing, and not exploratory testing, when I quoted Rapid Software Testing… well, in Rapid Software Testing, all testing is inherently exploratory and exploratory testing has been dropped from the RST namespace. Testing itself is not something that is informal, in fact, testing is skillful intellectual work. While testing might begin in informality, it does end in precision. This claim is evidenced in everyday life. As a runner, I tend to run on routes which I have not taken before. My initial choices might be informal and experiential as I search for new routes but as time goes by, I do get familiar with the routes to run on and am able to make new routes for varying distances. Starting with informality did not make my jogging session an informal one but the informality was necessary to begin with so that I may learn more about nearby jogging routes. It is the same with testing. Michael Bolton talks about necessary confusion and the bootstrap heuristic.

Image by Valiphotos from Pixabay.

                                

While someone might think that giving a new tester hundreds of test cases to do and asking them to write hundreds more would help the new tester to learn better testing. I found out that in my case, I came to understand testing better when I was not given any test cases, but heuristics to work with. 

 Test cases do not teach you to become a better tester as they may bias you into only finding the bugs that they are designed to find, thus limiting your opportunity for learning.

Testing can be boring for some, especially if you are given hundreds of test cases to perform. Or, when you are asked to write them in advance, only for your test cases not to be used since the requirements changed. Here is the thing, though it can be boring, it should not be. There is more to testing than test cases.

When I was introduced to context-driven testing, my thoughts towards testing changed for the better. Two of the seven context-driven testing principles state that good software testing is a challenging and intellectual process, and there are good practices in context, but there are no best practices. I went on to follow testers like James Bach, Michael Bolton, Ajay Balamurugadas, Brijesh Deb, Huib Schoots, Angie Jones, to name a few. By putting into practice what they were teaching and advocating for, I came to see real testing that is backed by skilled judgement, (social) science, and responsibility.

The context-driven community is helping me to become a better tester. Instead of spending time writing test cases, I now look for heuristics that help me to solve the problem at hand. With experiential testing, I get more time to uncover problems that matter and quickly. Whenever I test and something strange comes up, I can make an informed decision to follow up on it, rather than to blindly follow a test case. I document my testing as sessions using tools such as mind maps to my advantage.

Testing without test cases is also not experience-based. I encourage new testers to try it, as they can bring new ideas or ways of exploring that may benefit their teams and probably even the testing community.

 I am continuously learning and practicing, putting my newly found knowledge into practice so that I may become a better context-driven tester.

 

 Test. Explore. Shine the light on the problems you see.

 

 

 

Thanks to David Coomber, Klára Jánová, and Brijesh Deb for their help and advice on this piece.