Testing is a Team Problem
Written by Janet Gregory of DragonFire Inc, Agile coach and Quality Process Consultant.
During a recent Q & A session for my webinar ‘What a testing mindset brings to your agile team’, one of the participants asked me this question:
Why do you approach testing as a team problem vs quality as an overall responsibility of the team? Have you found that using it as a problem vs quality outcome is a way to help with the adoption?
Normally, I talk about quality as a team responsibility, but I didn’t in this particular talk, which focused on testing. However, this question made me think about the difference. I blogged on the quality subject here so I won’t repeat except to say, the conversation is hard for teams to have.
The other part of the question is what I will address in this post.
This slide is one that prompted the question. However, like all slides, it only shows a very small part of what I say.
When we approach testing as a team problem, we look at the testing question in a completely different way. Instead of making it a tester’s problem (or challenge), we can look at how all team members can use their strengths to make the product better, and in this case — as it pertains to testing.
Testing is tangible and can be broken down into concrete types of tasks. Teams can discuss who might be the best person(s) to do that task.
Let’s look at the testing problem and some of the ‘smaller’ challenges associated with it, and who might help.
What do we test? At a minimum, we could test:
- Ideas/requirements: testers, business reps, programmers (all from different perspectives) need to answer the question, “Are we building the right thing?”
- Code: programmers in the form of unit tests, anyone in the form or reviews need to answer the question, “Are we building it correctly?”
- The product/the system: testers, business reps, end users need to answer two questions. Before you start, ask, “What business problem are we trying to solve?” and then before you release, ask, “Did we solve the business problem?”
Using models (like the agile testing quadrants) enables the team to talk about which types of testing the team should do for ‘Story Done’, ‘Feature Done’, or even ‘Release Done’.
As a team, you could brainstorm using a mind map to help you think of specific tests that might be needed for a feature or story. By involving the whole team, you get multiple perspectives.
When do we start testing?
Using practices like ATDD (Acceptance Test Driven Development) means that you involve the whole team from the beginning. Note: you may know this practice as BDD (Behavioural Driven Development) or SBE (Specification By Example). The product owner — with acceptance tests and the team — vets those tests using examples to get to a shared understanding of what is going to be built, then collaborates with programmers to decide what automation is needed, followed by automating, exploring etc. before finishing up with the product owner (hopefully) accepting. And then there’s UAT, and load, and…
In other words, the whole team needs to be involved to help solve this problem.
What testing artifacts do we need? Considerations — regulatory, business needs, team needs.
— If you think about automated test results, you would probably need programmers or operations to help get the continuous results displayed and kept.
— We need to understand what the needs are from a regulatory and/or business standpoint, so we would need their viewpoints.
— How do we show coverage? Either automated/exploratory.
— What is the value of any artifacts created, either within the team or external to the team? Is there a way we could make it simpler? When all team members are part of this discussion, often we can find simpler ways of doing things.
How do we automate tests?
Using models such as the automation test pyramid, we can use the whole team to discuss which layer would be appropriate for any given test — thinking about value, visibility and maintenance. Better choices are made when the whole team is involved since it raises the level of transparency and trust within the team.
What else is worth automating?
Just asking this question opens the door for programmers to help testers or business users with automation, or testers to ask for help in automating or learning new tools to help them in their work.
As you can see, none of these testing challenges are small, but in my experience when the whole team starts to look at testing as a team problem, then the solutions are tackled in a completely different way using everyone’s strengths. If the testing problem is solved, by its very nature, the quality of the product will rise.
Remember two questions to ask if nothing else:
- What is the business problem we are trying to solve? — so, you can test for that.
- How are we going to test that for every story and feature to help make them testable within the system?
Originally published at janetgregory.ca
