At a high level, I think it’s fair to say “we should all own quality”.
I’d like to see a thread of practical examples of how you help folks own quality. What models have you implemented? What exercises have you run? What are you doing day-to-day to understand what whole-team quality ownership means, for real?
How are you changing people’s hearts and minds about who owns quality? How are you leading with quality?
And if you’re not, no worries – sometimes we’re not in a position to lead on or influence the conversation around quality. Let’s see what folks have to share on this thread.
Theres actually only been one product I’ve worked on that I felt the whole team truly owned quality.
What was different with that product to others was that we as team set our own OKR’s, we decided what features to add and what priority they had, we had almost entire ownership of product development.
It was does within a framework and business leader goal and guidance model and we could be overruled but I do not remember being so. That level of control is rare but is what is required for whole team ownership of quality.
Its close on many other products where we have an early team owned quality plan in place, a holistic view of testing fits well with this whole team idea so testers can contribute and in some ways drive quality.
Then theres a third group where whilst we succeed or fail as a team we are really only owning quality of our own work, this is not a bad thing, these projects also tend to go well but are often smaller than the ones that need active quality plans in place.
Worst cases, although I have not experienced in over a decade where it was viewed that QA or testers owned quality, dysfunctional painful experience with average products was the result, I tried and failed to change this at the time. I do not in this case judge myself too harshly for jumping ship.
Same as @andrewkelly2555 to a degree, I can remember one product many years ago.
It was desktop WPF app that drove electronic form filling for emergency service staff. The product had been designed with testability in mind from the outset, using a meta data engine to drive what sections and fields were displayed when. There were a collection of flow diagrams that explained what the paths through the application for each form as well.
When I came into the product I did a quick analysis of the front end and realised that the meta data was accessible from the front end. I realised I could automate tests from the outset. So I built a data driven framework built around this meta data. I created excel workbooks for each form, separate sheets for each section and created a naming convention for each field on those sheets. Within those sheets were uniquely identified data scenarios.
The test cases were drivers that identified the scenarios to run and the framework code would just cycle round finding the objects on the screen to drive the scenario. Every test used exactly the same code, the only maintenance ever required was on the datasheets. Which meant with a little bit of training any tester could create and maintain the scenarios, as the code barely ever needed touching.
It was the only product I could say there were zero bugs (to qualify that, zero bugs that the customer or engineering knew of).
Sadly I’ve never achieved that quality ownership since but its that golden goose that drives me on wherever I am to continue to coach quality thinking from the outset. I know its possible.
Day to day its hard work because in many places you feel you are seen as the “test team”, making assumptions of when we need to be involved. But when I hold onto that example, I elbow my way into the design conversation and try and influence. If I don’t feel the concerns are being heard (usually due to the false economy of getting a quick and dirty in front of the customer which becomes the real design) then I carry on trying to influence others.
So if you’re a way away from everyone owning quality, never lose sight of the Golden Goose. Get your foot in the door at the early conversations and try and influence the conversation. Keep at it as its going to be a journey. I’m still on it.
For several projects a deployment would take place. One system had to be replaced by another system. A third system had to be updated. All systems were connected. There was no test environment available to test all the new systems.
There were several deployment plans to roll out the system separately. But I had the feeling, that a lot of actions were missing. So I proposed to make one big deployment plan and do a walk through of each action.
Before I knew, I was the chair man and all involved managers and IT specialists took place in the meeting. I projected the deployment plan on a screen and updated it on the spot. Due to the collabarative meeting, the deploymnet went smoothly.
@simon_tomes changing hearts and minds is slow…But it starts with showing that quality is not just testing it’s about thoughtful design, realistic planning, observability, and fast feedback loops… I try to model curiosity and context-seeking when developers see testers diving into logs, asking “why” more than “what broke,” it sets a tone… And over the period of time you will see a shift… Developers start writing tests without being asked, whereas Product owners talking about the risk tradeoffs