Speed the Quality Nemesis
I’ve been reflecting on the last weeks and realized that a problem that I continuously face is the speed versus quality debate. For me I feel it is important to have a deadline. It creates a goalpost to get to. Whether that be the end of a sprint or a deadline to get this out the door and into production (for whatever business reason).
From my personal quality engineering perspective I want to get things out the door as much as anybody else, but we need to do it in the right way.
In some occasions there can be a “battle” between getting this out the door versus doing it with quality in mind. Hence the title of this blog post “speed the quality nemesis”. There is a push to send this out to production and yet it feels we have to slow down the business and think, have you thought about these outstanding things — the critical bugs remaining, the items that have not been addressed or project risks that are still open.
The way we have done this recently is created a Quality Engineering Report. On this it had:
- Exit criteria for the release e.g. the list of things that need to get done before we get this out the door
- A table with the outstanding bugs. We added a column “due date” and “owner”, so you could see what was being taken care of (or not).
- A table with the list of quality criteria stating if it was To do, In Progress, Done. I often use the quality criteria from the Heuristic Test Strategy, but mold it slightly to add some criteria that is important to us like “compliance”. Using Quality criteria I would highly recommend. It removes the “functional” and “non functional” language and looks at quality holistically. It has been a game changer in my career using this.
Benefit of creating a QE report
The benefit of this has been that it’s driven conversations about what matters and steering the team in the right direction!
Iterate on the QE Report Idea
If I could iterate on anything I would perhaps create this QE Report from the start of the project. We had an outstanding Test Plan although what we could have done is tracked against this somehow from the start. What you might find interesting also, is there is no sight of “number of tests” in our reporting. No Pass/Fail rates. So far, we’ve had no request for this type of information, which is interesting! Do we really need to share that info (I think not!)
Summary
Overall I don’t think speed should be the quality nemesis. All we need to do is have conversations about what good looks like throughout the project and get an understanding as a team what quality means to us and also have an agreed understanding of product risks. It was interesting recently when someone mentioned our release was low risk, however, spinning around from a different perspective, is that it was seen as high risk. This example can really depict why it is important to bring in different perspectives and have a conversation.
