Quality Assurance Isn't Good Enough

Does this sound familiar? A QA team member finds a bug. It's fairly high priority, but not a show stopper. He types up a bug report, includes a description of the issue, impacts to customers, steps to reproduce, screenshots, and copies of the log messages. He enters it into a bug tracking system. A Product team member sees the newly created ticket, and not wanting to interrupt the current sprint (something the developers complained about at the last retrospective) puts it at the top of the next planned sprint. She then shows up at Planning to make sure that the high priority bug makes it into the following sprint. After the next sprint begins, a developer fixes the bug. She marks it as complete, deploys it to the development environment, and moves on. The QA team member re-tests the fixed issue after its been deployed to the QA environment. The next build goes out. The issue is finally resolved. What's wrong with this picture?

Suppose the issue only took 5 minutes to fix and 5 minutes to test. What was the actual elapsed time to resolve the issue? In an organization with separate Development and QA teams, two week sprints, and staggered Development / QA sprints, the actual elapsed time could be as long as 6 weeks (two weeks before the next development sprint, two weeks for the development sprint where the issue is fixed, two weeks for the QA sprint where the issue is re-tested and deployed). The QA person might have even spent more time writing the bug report than it would take to just fix the issue. Something that could be resolved in 10 minutes, takes a month and a half! But what else is wrong with this picture?

How many people had to get involved? In this case 3 people got involved, and that's not counting the rest of the team that was present at any grooming / estimation / planning meetings where the level of effort required to resolve the issue, it's priority against other features, etc. were discussed.

Imagine that instead of doing things this way, the QA team member not only found the bug, but actually resolved it. Upon resolving the issue, he runs the tests and submits a pull request so that a developer can pick it up between stories and just make sure the fix is reasonable. The issue is resolved in hours or days instead of weeks. One less person is required to take action. An entire team (or maybe even 2 or 3) don't spend time discussing the issue in meetings. Thinking this way is what I call "Quality Ensurance".

"Assurance" means "a positive declaration intended to give confidence". "Ensurance" means "to make certain that (something) shall occur or be the case". The difference is subtle, but very important. Assurance is passive -- It's someone else's job to fix the problem. Ensurance is active -- I'm not only giving the green light, but also taking actions to get us there.

So why are we so tempted to do Quality Assurance instead of Quality Ensurance? Sometimes we copy team structures and roles and are afraid to step outside those boundaries. Sometimes we have incentives that measure our ability to follow pre-defined roles instead of what's best for the customer. And, well, to be perfectly frank about it, sometimes developers want us to believe that everything they do is hard. So hard in fact, that those without "Developer" in their job title are incapable of participating (as someone who has personally held the prestigious title of "System Developer", I think I'm allowed to make this claim).

So as to not completely alienate a third of my network, I'll concede that a good amount of what developers do is hard. And doing it really well is even harder. But let's get real -- sometimes a bug is just a text change. If we think we need three people, a planning meeting, and several sprints to make a text change, we're doing something wrong. In fact, if you have people in your company who after a little bit of training are incapable of making a simple text changes to your system, you may want to start questioning what kind of people you're allowing into your company. You may also want to start questioning the "experts" who have put in place a system where simple text changes so difficult. It's 2017. It's time we start letting other people make simple text changes to things like websites.

If you've made it this far and the last paragraph didn't cause you to click the "Unfollow Chris Harbert", then you've probably conceded that there are at least some cases where it makes sense for QA teams to be more pro-active and help to ensure quality instead of merely reporting on it. So how can you get started doing Quality Ensurance?

Provide basic training for how to fix simple bugs. How do you checkout the projects? How do you commit changes? What tools are in use? What resources are available if you get stuck? How do you tap out when you've found a bug that's too complex? It's not fair to expect people to do something new without showing them how to do it.

Establish a time-based guideline for when to fix and when to report. For example, you could say something along the lines of "If you think you can fix it in less than 30 minutes, try to do that. If you find yourself spending more than an hour, stop and put in a ticket."

Involve QA earlier in the process and more often. An even better way to ensure quality is to involve QA earlier and more often. A good QA team can help review requirements and write acceptance criteria (aka conditions of satisfaction), before development even begins -- decreasing the number of bugs that actually get created. They can also write tests before the code is written, and run them frequently during development sprints.

Make it formal. It can be difficult to get someone to do something new that requires someones time without changing how they are held accountable. Sometimes updating job descriptions, including items in performance reviews, and changing incentives (e.g. stop rewarding based only on reported bugs found) is needed to bring about the new behavior. As a QA Manager who is likely held accountable for the end result (bugs reported, quality of the system, etc.), you should be willing to put in the work to make these changes. Your job may depend on it.

So what do you think? Is Quality Assurance still good enough? Or are you ready to try Quality Ensurance?