While there are many complex ways to answer this question, I found the below definition clear and simple.
“A defect is a deviation from requirements.”
The starting point, then, of preventing defects from getting logged is ensuring that the entire team which will be working on the backlog thoroughly understands the requirements in detail. One thing that has always worked for me is collective team discussions, closed room meetings held with the primary objective of fleshing out all the core requirements and publishing the questions to be submitted to the Business Analyst or the actual end users. Analysing all aspects of requirements can never be an individual job, getting the whole team involved at an early stage ensures that nothing slips through the cracks.
Key steps to be followed:
- Get hold of the sprint backlog
- Get all the developers into the Team room and dissect each User Story and list down gaps
- Post the entire set of questions coming out of the requirement and impact analysis on the team wiki (if you are not using one, well, then you are probably wasting too much precious team time on emails and con calls)
Missing Acceptance criteria
As part of the requirement and impact analysis, sniff out all the missing acceptance criteria for each User Story. For each missing acceptance criteria which you find at this stage, you will be preventing many defects from getting logged later on.
As illustrated above, every User Story has multiple acceptance criteria, every Acceptance Criterion translates into multiple Unit Test cases which when executed thoroughly leads to a defect free delivery. This is one of the core principles of defect free delivery.
Plan out / estimate the unit testing effort at the sprint planning stage itself
Make sure all your time estimates include sufficient time for performing unit testing for each user story. If you have a good track record of delivering defect free code consistently, none of the stakeholders will question you on these efforts.
Moreover, there are many software contracts which have clauses like “ZDC – Zero Defect Code”, “100% code coverage”, etc built into the contract. It is not possible to achieve compliance with these clauses without having a rock solid unit testing strategy in place.
Ensure high Unit testing coverage
This is a paradigm shift in thinking for the individual developer who has been conditioned to think all along that “testing is not my responsibility”. Getting your developers to move from this foundational belief to “Quality is everyone’s responsibility” is a journey in itself, one which will take some time, probably 2-3 sprints. The whole structure falls in place when the team starts taking pride in achieving close to zero defect deliveries and this becomes part of the team culture. Each developer needs to ensure that for the User Story he has volunteered to work on, all the acceptance criteria mentioned are getting tested based on the unit tests he / she has written. This is crucial.
Put a defect RCA(Root Cause Analysis) definition in place
As part of the defect lifecycle, for every defect that is logged by QA please ensure that the individual developer responsible is mandatorily required to choose the root cause of the defect from a list of pre-defined root causes.
A sample listing of potential root causes is provided below:
| Sr.No | Classification | Description |
| 1 | Requirement | The requirement has not been clearly understood, the team’s assumption does not match with the business user’s expectations. |
| 2 | Impact Analysis | Thorough impact analysis has not been done and implicit requirements have been missed out |
| 3 | Wrong implementation | The defect was caused due to an incorrect coding implementation |
| 4 | Testing error | The test case was incorrect effectively resulting in an invalid defect getting logged |
| 5 | Configuration | The defect was caused by incorrect static data setup |
| 6 | Existing bug | This is an existing defect in the system which is probably also present on the live environment |
| 7 | Injected defect | This defect has been injected due to a different defect fix. |
| 8 | Environment | The defect has occurred due to a code base lining issue, server level configuration, etc |
You could use this as a baseline for creating your own RCA matrix as per your project needs.
Conduct weekly defect retrospectives
Some practices that have worked well for me are listed below:
- Ensure that all the developers attend the meeting
- Time box the meeting to 1 hour
- During the meeting, go through each and every defect, check if the RCA is correct, ask the question what could have been done better to avoid logging of the defect, etc.
This is a very effective meeting as it sensitises the developers towards adopting a more responsible approach towards their work and also ensuring that they deliver defect free code of high quality. Ideally, try to cover all the defects logged in the defect retrospective meeting.
Once you do this consistently, an interesting trend will commence. You will notice that the defect count will show a sharp dip and developers will be extra careful towards ensuring that they do not introduce any new defects. Within 3 sprints, you will observe a drastic reduction in the volume of defects and once this is achieved, it will stay that way.
Why is the defect retrospective so powerful?
- It’s basically reflection, consistently holding up the mirror and seeing things as they really are.
- It’s unadulterated, undiluted feedback
- It is self-corrective by design
Have a strongly defined check-in policy in place
Most of the ALM (Application Lifecycle Management) tools in use nowadays, for e.g. Microsoft TFS provide you the ability to customize the code check-in policy as per the requirements of your project. Some effective customizations are mentioned below:
- Ensure that every check-in is mandatorily reviewed by the team lead and at the point of checking in the code, the name of the person who has reviewed the changeset ia mandatorily recorded.
- The purpose for which any check-in is being made also needs to be mentioned as part of the check-in comments for e.g. for a defect fix the defect id needs to be mandatorily mentioned.
- Activate Email check-in notifications
- This serves a dual purpose:
- For every check-in that is committed, all the team members, the team leader and the project manager get an email alert providing low level details about the changeset which was just checked in. It provides details on which source code files were modified, which files were added, etc.
- This triggers off a rapid, self-corrective mechanism. The moment someone does a bad check-in, other developers swoop in to get it corrected since they the impact immediately due to the email notification.
All these customizations are very effective in bringing in greater accountability and discipline in the development team since all their actions are openly visible and as you might be already aware, high degree of visibility is one of the key pillars of Scrum.