How to Make Quality a Team Effort
Throughout my career, I’ve heard others say that quality should be a team effort.
But exactly how do you make that happen? Especially when you are a tester and people tend to assume that you are responsible for quality.
In this post, I will share a few ideas to help make quality a team effort.
But first, let’s reframe the question to make it easier to tackle.
How to Make Quality a Team Effort?
To be honest, I find this question a bit hard to answer, an easier way to look at this is:
How can the team contribute to quality?
or
How can we, as a team, make sure we build a high quality feature/app/product?
What are people’s expectations?
I like to get an idea of my team’s expectations regarding:
- Who is responsible for quality?
- What should a software tester do?
It’s great to have a starting point and to have people explicitly state what they think.
While, it’s easy to say “Quality is a team effort” or “Quality should be a team effort”, I find it can be a bit harder to get one’s head around this when you have a dedicated tester in your team.
At this stage I would also manage expectations about what I believe my responsibility in the team is:
To test software, so we can make informed decisions.
I believe, what I do as a software tester, doesn’t just impact quality (i.e. if I am able to prevent bugs) what I do actually impacts perception. My testing affects the perception of the product’s quality.
If my testing reveals a lot of major bugs, then my team may believe the product is of a low quality. If my testing doesn’t reveal any bugs, then my team may believe that the product is of a high quality.
Gather ideas from your team
Now that we have an idea of what people’s expectations are, I would ask people what they have done before to ensure the team builds a quality product.
This could be done in a few ways, including:
- Slack
- Hold a meeting to specfically discuss the issue
Once you have these suggestions, I would take note of them and then see if you can integrate them into a Way of Working.
Introduce a Way of Working
If your team doesn’t already have done, I strongly suggest you bring up the idea of introducing a Way of Working (WoW) to your team. A Way of Working is a great way to clearly state what people are expected to do, which can help make quality a team effort.
Examples include:
- Developers write unit tests
- Have feature kick-offs when you start on a new feature, so that everyone can ask questions, share their concerns etc.
- Hold bug bashes so that more people
- Pair test with others in your team so that you get to learn from each other, but more important so you get to share your testing knowledge.
- Have developers write test automation (they could assist or be in charge of, I would say this depends on the skillset of the tester)
- Code reviews
- Suggest that others pair test without you (no tester is part of the pair)
I would not feel pressured to change everything now and be too ambitious. You can always update your WoW.
Make sure you only add to your WoW, what your team can realistically commit to.
Try it out
Your team may have ideas that you are reluctant to commit to, but are still worth pursuing.
In this case, I recommend you discuss with your team:
- What the change would be
- The timeframe
- What you hope to achieve with the trial
- How your team will decide whether to continue with the change
If you are interested in learning more about how the team can get involved with testing (and in turn contribute to quality), then check out Lisi Hocke’s The Whole Team Approach to Continuous Testing course on TestAutomationU.
#Learning and Improvement #Popular #Testing