Too Many Defects/Bugs, Don’t Just Look at Fixing QA

November 16, 2016 — Posted by Maurizio Mancini

In many engagements upper and middle management ask me “How do we fix our Testing (QC) process? The team is just not catching the defects”?

What I have asked these managers in return is; “Why focus on fixing your testing processes first, shouldn’t you first focus on fixing the development process since they write the code?”

This usually starts a vigorous discussion about where the problem really lies in the organization, which is exactly the kind of soul searching an organization needs to do when they ask me to fix the testing.

Fix the Root of the Problem and not Just the Symptom

The objective in asking my question is to get the organization to think. Why would you spend budget fixing a symptom of a problem. It is not the testing staff that wrote the code or wrote the story. The process starts with other team members, so the organization needs to do a holistic review of the entire process to really address the issue.

If we take an example from the car manufacturing industry, when a recall occurs, the manufacturers don’t just say “we need to fix how we test the piece being recalled”. Given the direct and indirect costs associated with a recall you can be sure that the manufacturer has spent time reviewing the entire process.

In my opinion, I think software organizations need to do the same thing. Software is at the core of most businesses these days. Having software that is working properly and optimized is essential to staying competitive. So why wouldn’t you do a proper analysis of the entire software process if you have an issue of too many defects?

QA Is an Easy Target

Given the nature of the QA role which is to find problems in other people's work, it is an easy target to shoot at when it comes to bugs. “Why didn’t QA catch it?” is the first question on everybody's mind when a problem occurs.

You won’t hear, “what was the User Story that caused this bug”?

While QA is an easy target, it unfortunately detracts from addressing the real issue, the software engineering process!

For software engineering teams to evolve and mature, they need to own the software they deliver as a team.

When a Bug hits Production, the Team Should Feel the Shame

By “owing it”, I mean that they need to feel pride in the software that they deliver. It is not “just software” but rather software that runs a business. When a bug hits production, the team should take ownership of analyzing the bug and seeing what caused it. This should be a regular activity especially in an Agile team that is delivering software in production on a frequent basis (ex: every 2 weeks). Agile teams should be encouraged to include time for defect analysis in their sprints, so that they can get to the root of the problem sooner rather than later. By having defect root cause analysis with every sprint, it ensures that the amount of technical debt in a software does not grow out of control and eventually become the majority of where your software engineering dollars are spent.

If you don’t manage technical debt, it will manage you.

How Agile has Helped Remove the Target from QA

When Agile started to become more mainstream about a decade ago, many QA teams felt threatened. Why shouldn’t they feel threatened, Agile was “supposedly” advocating that QA people were not required.

However, if you look closely at Agile, it is actually a huge advocate of building in quality and calls for everyone on the team to own quality. Agile/Scrum calls on the Product Owner to produce clear Stories and Acceptance Criteria, the Dev team to test their code, QA to be involved with the Dev team from the start, and of course have customer involvement whenever possible.

Agile has helped remove the target off of QAs back because it has helped share the responsibility of ensuring that the software delivered is quality software. By sharing the responsibility for quality, it has helped to highlight that there is enough testing to go around. It has helped QA staff to focus on actual testing of the features being delivered, rather than on managing hundreds of defects from a poorly delivered build.

More importantly, Agile has helped an organization look at the entire process of software engineering, rather than just trying to “fix the testing” when defects occur.

If you want to know more about how to review your engineering process to solve problems at the source, please​ ​contact Exempio or Net Objectives​ for a consultation.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Maurizio Mancini

Maurizio Mancini is a leader in the quality and process industries with a sixth sense for Agile, quality, and business process. He is best known for cutting through the noise and getting to the heart of any organizational problem whether that problem consists of choosing the right software development process, implementing modern quality approaches, or just finding the right balance between people, process and tools. Maurizio’s approach consists of empowering people and teams so that the team's talent and creativity comes through naturally. This mindset favors the adoption of Agile values in any environment.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban