Reading:
Different Testers, Different Processes
Share:

Different Testers, Different Processes

Applying Learning Styles to Testing: Article 4 of 4

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:

  1. Merriam, S. B., Caffarella, R. S., & Baumgartner, L. M. (2007): Learning in adulthood: a comprehensive guide. San Francisco: John Wiley & Sons, Inc.
  2. [kolb84]. Kolb, D.A. (1984): Experiential learning: experience as the source of learning and development
  3. https://en.wikipedia.org/wiki/Kurt_Lewin
  4. https://en.wikipedia.org/wiki/Experiential_learning
  5. http://www2.le.ac.uk/departments/gradschool/training/eresources/teaching/theories/honey-mumford
  6. https://www.16personalities.com/
Beren Van Daele's profile
Beren Van Daele

Businessman

I lead a company: Isle of IT

Together with like-minded people who value communication and transparency above all else, we wish to grow a company that enables people to be themselves. Experts to the outside, a fellowship on the inside.
Each member has the freedom to pursue their own merit, whatever that looks like, while also bearing a responsibility to the continuation and growth of the company. With full transparency, we aim to facilitate communication between members to find a balance that makes sense for themselves.

I am a Consultant:
I am a consultant who shapes software delivery teams to improve on their work and their understanding of quality. Once a Software Tester, sometimes a Product Owner, I travel around, meeting software crafters all across Europe to learn from and teach.

I create things:

  • TestSphere, a testing card game that inspires and supports knowledge sharing
  • RiskStorming, a workshop that focusses the team on quality and risks
  • RiskStormingOnline.com is RiskStorming for the remote world.

I do conferences:

  • BREWT is peer workshop for testers. (organiser)
  • ITMatters is a conference for Diversity and Inclusion in IT (support)



Minding Your Own Business - Lisa Crispin
Balancing Test Automation Techniques - Matt Archer
Software Testing Roundup
Testers! Be More Salmon! – Duncan Nisbet
How We Created Delivery Teams Focused on Quality – Stuart Wright
Why Does Automation Fail? – Tanya Kravtsov
Explore MoT
TestBash Brighton 2024
Thu, 12 Sep 2024, 9:00 AM
We’re shaking things up and bringing TestBash back to Brighton on September 12th and 13th, 2024.
Cognitive Biases In Software Testing
Learn how to recognise cognitive biases, explain what they are and use them to your advantage in your testing