If you are an engineering leader that strongly believes testing should be a team effort but have struggled to make it happen, keep reading. We have practical tips that go beyond the usual advice of writing unit tests, improving code reviews and aiming for better test coverage.
Since 2013, Qxf2 has been testing early stage products. Our approach evolved from owning testing to figuring out how to get teams to own the testing and quality of their work. Along the way, we realized there is a lot more nuance and depth to making this mantra work. Many of these tips come from the mistakes we made along the way. Here are some tips on how to get your developers to own testing.
Fig 1. Summary of the article
1. Your preparation
As a technical leader, below are a few points to consider before encouraging your team to successfully take ownership of testing. We have listed these points to draw your attention to them. However, we haven't provided specific solutions, as the best approach will depend on your leadership style.
Fig 2. Prepare to improve team ownership of testing
2. Implementation
Once you have completed the preparation phase, it is time for planning and executing the implementation phase with your team. This phase involves putting your prepared strategies into action and ensuring that everyone is on board with the plan. Here are some critical components to focus on during the implementation process
Fig 3. Formulate a plan and implement it
Fig 4. Evolution of test coverage at companies
For early stage products, we recommend that you aim for 'multi-layer sparse' test coverage level. A 'multi-layer' defense means adding very few UI tests, some API tests and some regular exploratory testing to your existing unit tests. But it also means a whole lot more. There are other things for your developers to work on - like creating synthetic data for repeatable tests, virtualizing services to enable developers to test on their own machines, data quality checks, infrastructure tests, contract tests to decouple teams, alerting and monitoring, etc.Fig 5. Typical toolbelt that Qxf2 engineers work with (as of 2023)
Well, we have so much experience on this topic that we could write a book filled with counter-intuitive insights. If you do need help at this stage, just write to [email protected] and we will be happy to share our expertise.3. Risks
All strategies come with risks. We have a large list of risks. To keep things simple, we have listed the top 5 risks you need to be aware of when pursuing team ownership of your testing.
Fig 6. Risks when you try to make testing a team responsibility
4. Other options
When things go bad, we see many companies try to tackle the problem by adding surface level testing. This is usually in the form of hiring a relatively inexperienced tester. The problem is much deeper and involves getting the team back on track to owning testing and quality. Qxf2 usually goes through a more thorough but quick 5-layer analysis to arrive at a suitable testing strategy. A lot of our work in such situation involves setting up critical defenses, improving testability, selecting the right technical stack for your team and then enabling your developers to write tests that matter. You could consult with us or hire a senior tester and give them the goal of getting your team to own the testing.
Closing thoughts
This article was written by Avinash Shetty and Arunkumar Muralidharan. Our understanding of getting teams to own testing has accumulated over the years. One article cannot capture our ongoing journey of learning and improving.
Fig 7. Testimonials from Qxf2 clients showing our evolution in approach
We have had to leave out a LOT of what we know just to keep this article to a reasonable length. So if you want us to elaborate on anything in this article or want to share your own experience on the topic, please reach out to Avinash ([email protected]) or Arun ([email protected]).
© Qxf2 Services 2013 -