One word which keeps appearing in my conversations about software quality is “confidence” and it’s an underrated word which is ridiculously hard to quantify. Let me give you an example; I was asked how many automated playwright tests were needed by another QE, to which I replied; We need to build upon the unit tests, filling in the gaps, to enable developers to push their code changes with confidence.
Why with confidence? Why not to guarantee that it’s bug free? Well, we can’t guarantee that their code changes will be bug free. Time and experience has proven, again and again, that adding more tests doesn’t equate to bug or issue free software, however we can focus our testing to maximise our confidence in the quality of the product and the change, minimizing risk.
Confidence doesn’t just relate to developers either, stakeholders need confidence too. They spend a lot of money on teams, to create a vision, often abstracted so far away from the daily software development cycle that they need project management and testing reports, to allow them to see progress, react accordingly and have confidence in the work carried out.
When they hear that there’s been a critical bug reported in a live system, confidence drops, questions start to pop up; Why did this happen? Who is to blame? It’s vital that we build up confidence in software quality, it’s why teams are asked to create test plans and strategies, why test reports are created and so often ignored as stakeholders don’t know how to consume them. Confidence is lost and the cycle continues.
I’ve spent a long time investigating how we can improve confidence at all levels. In the way we test, how we build test strategies, how we communicate, coaching teams to shift left and make quality a key player at the table from the start of each development cycle. The one thing that stands out in building confidence in quality at all levels is clear communication.
While introducing shift left as a concept for the first time, I encountered resistance, developers didn’t like it and thought they were being given more work (automating more tests) and asked what testers would really be doing. This happened because they didn’t clearly understand the problem that shift left was trying to solve, they weren’t involved in identifying the pain points, indicating the problem and creating a solution. They saw a change, saw more work involved and had very low confidence in the solution. To build confidence, you need to involve people in the process, allow them to own it and guide its changes.
Looking back at stakeholders, if a stakeholder asked you how confident are you in the quality of the product, could you answer? How would you answer?
I’ll admit, I struggled with how to answer this kind of question too. This lead me to start looking at process maturity models, ways to map out how we test, to identify key areas which need improvement and to quantifiably show progress over time.
One of my favourite maturity models is the Quality Practices Assessment Model (QPAM) by Janet Gregory and Selina Delesie. It allows you to build up a map of agile development quality practices, clearly identifying where your strengths and weaknesses are. This helped to build up stakeholders confidence in the teams quality processes and also helped teams to build up confidence in why processes are changing, visualising growth and seeing results.
So why did I write this article? Why am I mentioning confidence so much?
I believe that software development and testing practices are ever changing, always evolving, however one thing remains constant; the need for confidence in our software’s quality and the processes in which we make it.
I’ve been collecting ideas and formulating a way to assess and build quality confidence. Building upon existing models, like QPAM, adding in a change framework, ways to assess friction points, how to measure risk and wrapping it all up in a new model which takes a more holistic view to quality and helps you to visualise and improve it, building up quality confidence at all levels. The Quality Confidence Model.
I hope you’ll follow me on this journey, give me feedback, try out the model and help it evolve and grow.
2026 is going to be a Quality year!