What can we do to help teams build great software?

I’ve had great success in my career using Testing to help make better software. Sometimes it’s better by way of being less buggy, and sometimes I’ve been able to spot a missing feature.

I love Testing. Also, what else can we do to help teams build great Software?


I also love testing, if I ever move from a dedicated testing role to something else, it would have to role that is at least partially involved in testing.

I think as testers it’s good if we take more of a proactive approach, not just validate features, report bugs and automate some checks, but try to get other team members more involved in testing, now this greatly depends on what kind of company we’re in and how mature and how open the team is to learn and experiment.

  • We can love our job, and always encourage everyone in the background.
  • We can welcome agile experiments, and be the “eyes” of the team (a bit like headlights.)
  • Be a good communicator, (by that I mean being clear, not being good at standing on stage.) It’s just a key skill of this position.
  • But most of all take the job seriously, do your homework, know the field. If you screw up, it’s like the goalie letting one through.
  • Be the backup person in the team, a bit like the quarterback in a football team, ready to fill in any gaps. But most of all relax, you are not the police.

Great question!

It’s almost overwhelming to think of all the possible answers. The first ones I think of:

  • Help the team get better insight into the effect of their releases (feature uptake, user behaviour changes, customer support tickets, error rates, performance deltas)
  • Help the team with their incident response (improve the dynamic alerting, take a systems thinking approach to postmortems, sanity check the incident playbook and on-call agreements)
  • Help the team find gaps in test activities most relevant to them (test coverage at different levels of test automation, cross-functional testing)
  • Help the team make incremental improvements to ways of working (better product discovery, experimenting with different collaboration methods, making work smaller)
  • Help the team with their test automation (do the unit and integration tests cover what they should cover, do they fail for the right reason, can testability be improved)
  • Help the team gain product and domain knowledge (write documentation, improve existing documentation, organise lightning talks or brown bag sessions)
  • Help the team more safely release more quickly (introduce or improve canary releases, feature toggles, beta community releases)

Start with what “great” means. Great to whom? “Great software” is fine as a marketing term or as a pick-me-up in a company meeting, but it doesn’t really mean anything. We can make software fast, responsive, secure, marketable, profitable, to the demands of our shareholders… “great” is partly making something to be proud of, but partly making something under the instruction of those that pay you. You need to balance your views and values with the company - maybe great software to you is accessible to the differently abled, LGBTQ+ inclusive, low carbon emissions, has privacy for its users, and maybe you could fight for them even if the general consensus is that they’re not profitable ways to spend your time. You could raise issues like “this software doesn’t meet the minimum legal requirement for accessibility” (many don’t), and you could even fight that corner, but ultimately your job is to be of service to the people in your team and those who pay for you to be there. Perhaps.

Sometimes I’d raise issues of inclusivity or accessibility, and I’d lend weight to my point with ways it could help the software be profitable or a need for someone with legal training to look at it, and sometimes it would get fixed, other times ignored and I had to let that one go. It’s not my job to write the roadmap, just to provide my views and insights, whether they be obvious (“smoke comes out when you turn it on”) or not (“If we’re asking for gender maybe male and female isn’t enough of a list - or maybe we don’t need to ask”). Ideally software teams are given enough independence to build software within their team without interference, but that independence also gives you a responsibility - is that responsibility to your contract, your company, your team, the users or the planet? And if you can’t have all of them how might you balance those? Micromanagement is a matter of a lack of trust - but if you’re really given that trust how will you use it?

So how to help make great software? I’d say be supportive without being subservient. Subversive without being revolutionary. And think about what it means to be an effective, helpful, but moral tester. Think hard about your context and the values and goals of people around you, and how they’re balanced, because context defines the value of anything you say or do.


Indeed. “Great” can have many meanings in this context. I got my company to embrace accessibility, for example, by saying that if one of our existing customers had a valued member of their team who acquired a disability, if we couldn’t make our software usable for them with the “necessary adjustments”, it could mean that they might turn away from our product and buy the Brand X product that was inferior to ours but accessible for their preferred user.

Sometimes, helping make great software is about outlining ways that we might miss greatness.


Its better to start at the top. First, make a practical and useful onboarding program which covers relevant features well. If you don’t know the product well, then you can’t be effective at testing. Next, improve developer and product manager education and hiring practices. Once the requirements and coding style gets better, there will be far less bugs to find. Add good automation tools to the mix to make development and testing easier. After that, QA can find any missed bugs.

1 Like