Be this tall to do Quality Assistance

Do you want your organisation to adopt a quality assistance model? Have these in place before you adopt the model.

Software Engineers who Test

Your software engineers understand and agree that all software testing is part of their remit. And that means hiring engineers with this in mind. (I call this move the ultimate shift left). If you hire software engineers who would prefer QA's or test engineers to do the testing, constant friction will make the quality assistance model hard to adopt. The shift is possible, but it takes conscious effort from senior leadership. You will need to make significant changes around engineering role descriptions, hiring, and interviewing, and that's just for new hires. Coaching and training programs on software testing will be required for existing software engineers to help them understand their new scope and ways of working.

Engineering Leadership Own Quality

You can't expect teams to take on additional work without ensuring senior leadership sets expectations around quality. Ownership starts at the top. If you are serious about maintaining good quality, consider what behaviours senior leadership must demonstrate to back that up. Consider setting quality-related OKRs tied to company success. Too many senior leaders pay lip service to quality, believing that the "team should decide". In my opinion, this is a cop-out. One of the benefits of the quality assistance model is that the buck stops with leadership, which means they make the tradeoff on quality evident to everyone.

Enabling Teams

You must have a robust enabling team that develops and maintains test automation tooling required for a quality assistance model. These software engineers will build and maintain any necessary tooling. They can create and embed blueprints into newly created repositories, enabling product teams to begin test automation immediately. You don't want software engineers having to maintain these tools, so invest here.

Modern Engineering practices

Small slices of customer value, rapidly deployed to production, feature flagging, distributed tracing, monitoring, and alerting offer diverse risk mitigation approaches. Small slices of work reduce the risk of failure, and canary releases minimise the impact of failure. Monitoring and alerting help you identify issues, perhaps even before a customer knows them. Distributed tracing facilitates the fast identification of problems.

Modern engineering practices are essential because software engineers should not be expected to perform software testing at the same level as specialised quality professionals who test all day. Also, confirmation bias is real. Spotting issues in other people's work is easier than your own. For these reasons, having alternative risk mitigation strategies minimises the impact of a software engineer missing a bug. If our software testing misses a bug, there's a solid chance we will find it through other methods.

Context Matters

Of course, the quality assistance model is not applicable in some contexts. If I deal with a massive legacy system with intricate dependencies, I want software test engineers with SME knowledge on my team. They help with early identification of unknown dependencies, customer usage and many other elements.

In other contexts, there may be legal and compliance reasons why a quality assistance model won't work for you.

Don't unthinkingly follow what's new and attractive. Be sensible when assessing your company's context and risk appetite. Critical thinking doesn't stop at testing a product. Advise your company to consider risks and context when adopting quality approaches.

Finally, if you are a quality professional weighing up whether your company should use quality assistance, carefully identify and observe how your leadership team is performing. If you are expected to drive change with zero budget and through 'influence,' be aware of the limitations of what can be achieved. I would avoid committing to anything the engineering leadership is unwilling to invest in, whether advocacy or budget.

Have fun!

Quality Coach Assistant

Welcome! Ask about quality coaching, leadership, and engineering culture.

How can I start improving quality without slowing delivery? What should I focus on first as an engineering leader? How do I coach teams toward better systems thinking?