Menu
In many engagements we come across upper and middle managers that ask us “How do we fix our Testing (QC) process? The team is just not catching the defects”?
We usually start this discussion by asking these managers a question in return; “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 to fix the testing.
The objective in asking this 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 writes the code or writes 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 our opinion, we 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?
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.
By “owing it”, we 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 software engineering dollars are spent.
If you don’t manage technical debt, it will manage you.
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 QA’s 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 need help in doing a holistic assessment of your organizations software engineering process, please contact us for a consultation.