This is where the theory stops, yet there is still much to discover. The next part is pure speculation. If we have four different test styles, how do we get them to work together effectively?
Requirements Based Testing
Thereâs a very good chance that this way of managing your testing is the first one youâve learned. Itâs popular in certificates, consultancy, standards and is widely used in many large companies.
Requirements build us an abstract concept of what the product is to become. Whether those requirements are documented, tacit or explicit, communicated or spread among different stakeholders, the test team focuses on gathering those requirements and building an analysis around it. This can take many forms. The most popular one being Test Cases/Scripts/Steps or any way you want to call an Action â Expected Result relation.
The next step in the process is to validate those requirements. When there is a mismatch, the implications of this digression is investigated and explored in an atypical, unstructured way. Finally, a conclusion is drawn or decision made and either the requirement is adjusted, added or a bug logged. This is where The Theorist fits right in.
Session Based Testing
On the complete opposite side of the spectrum, we have The Activistsâ concrete process of Test Management. Here, maximized time with the product is valued more than anything else within testing. This philosophy is focused on experiences and learning from them. Exploring implications and investigating.
It starts with one person embarking on a mission with a clear goal. Like a captain on an adventure, he holds a log and vigorously takes notes. These notes describe possible problems, red flags and new opportunities. Anything that might be useful one day. Together with a mediator, who tries to keep an objective and impartial role these new findings are discussed. Sometimes, models are created or connected to old information. They try to make sense of the new information from this mission.
During this process of working together, new ideas sprout from this cooperation. These are a basis for new charters, for new missions. The circle starts anew.
Mob Testing
Two lesser known, or lesser practiced Test Processes, Strategies, Management methods or whatever you wish to call them are Problem Oriented Testing and Mob Testing.
Words are troublesome. I donât have a specific word for this process, but Mob Testing comes close. Especially in a User Acceptance situation.
This process starts with the question âwhat does the product do?â. But itâs not just you whoâs coming up with answers. No, itâs a whole group of people. Testers and non-testers alike! With an Observer at the steering wheel. As a group you build a model of the product, whether thatâs a brainstorm outline, a mind map, a tapestry of Post-It notes or something else. It doesnât really matter, as long as the product is visualized.
The importance lies with the observations of the group made concrete (in a high level way). The resulting knowledge from these observations is your basis to analyse the question âWhat is the worst thing that could go wrong?â. Here, the group taps into a different kind of knowledge. They consider risks, connections and high impact scenarios.
The following step can differ greatly. The group can test as one organized being, or individually, in pairs⌠However they do this, they are exercising the possible doom scenarios from before and learning through their experience. Naturally, these tests flow into exploration of new findings. And as a result, the model will have to be readjusted. And so it starts againâŚ
Problem Oriented Testing
The last process is what I have come to call the Problem Oriented Testing method, but I suspect it would fit tightly to what âRapid Software Testingâ by James Bach and Michael Bolton would look like, should it be formalized into a circular process. Though I canât be sure. This is speculation. âContext Driven Testingâ certainly comes close as well.
In any case, the Problem Oriented Testing process puts its focus on the Testers themselves. Their previous experiences and their earlier learnings. This knowledge is the basis to evaluate the product.
The Tester herself has found, created and gathered certain heuristics during her career (a fallible method to solve or identify a problem). These heuristics help the Tester to find problems, where others would miss them. This ability is what distinguishes him from new testers or non-testers. Be sure to hone these skills.
Whenever the Tester runs out of ideas, she starts exploring, playing with the product. Which leads to new experiences and new insights. These in turn are observed and explained and the result becomes fuel for the testerâs imagination and curiosity.
The Pragmatist now has several new heuristics to take him to the next phase and the next project.
Impact on your Test Strategy
Youâve come to understand the Learning Styles and how they influence our testing. Youâve come to see what goes on in the background when you make choices, when you approach a new project and when you start testing.
Youâve gotten insights in how Test Styles fit into our Processes, Strategies and Test Management Methods.
You are you⌠and there is not much to be done about that. Yet, if you keep in mind your weaknesses, you can prepare to counter them: by adjusting your own behaviour or by taking advantage of the qualities of the people around you. Empower and strengthen each other.
From the very moment we formalize one way of working, one method of testing we are already alienating people and running the risk of missing important information.
Whether we want to or not: when weâre deciding upon a way to manage our Test Process, weâre biased one way or another. If youâre ever in the position of choosing a Test Process, consider a more flexible approach. Create an environment where people can test in their own Learning Style, but make sure you challenge them to try and keep trying new and other Learning Styles. Switch the Process around once in awhile, learn to read the situation and adapt the process as necessary.
There is no âone best wayâ to manage any testing. There is not even a âone best wayâ to manage your testing. In order to find as many bugs, as many risks and possible hazards, you need to adapt, adjust and pursue variation. Your process should reflect that.
- If you learn differently
- And you test differently
- And everyone around you does too,
- Why would you stick with one Test Process?
- What are you missing, if you do?
Sources:
- Merriam, S. B., Caffarella, R. S., & Baumgartner, L. M. (2007):Â Learning in adulthood: a comprehensive guide. San Francisco: John Wiley & Sons, Inc.
- [kolb84]. Kolb, D.A. (1984): Experiential learning: experience as the source of learning and development
- https://en.wikipedia.org/wiki/Kurt_Lewin
- https://en.wikipedia.org/wiki/Experiential_learning
- http://www2.le.ac.uk/departments/gradschool/training/eresources/teaching/theories/honey-mumford
- https://www.16personalities.com/
.png)
