Академический Документы
Профессиональный Документы
Культура Документы
The defects fix phase starts as the development team completes the coding and
unit testing and moves the code to integration testing and/or system integration
testing phase (Please refer the below figure)
System
Integration
Continuous Integration UAT
Developer Testing
Build Testing
workstation
machine
Note: Integration Testing – Interfaces are being tested; System Integration – End-to-End business process being
tested
This phase is very crucial due to fact that the software is not yet stable and the test
scenarios covered during integration / system integration are wider than the scope
of unit testing. Once the defects are logged in large volume, the development team
may point them to ‘lack of design time’ or ‘refer-this-email-chain’ or at the worst
case to compromise on the software engineering practices to do a ‘quick-fix’.
Traditionally software development vendors may trim the development team size
during the development support phase, which does not help either.
Enough was said on the problem statement, what is the way out? Truly speaking,
the solution is yet to be derived. . I have tried to package a set of practices based
on my experience that would help us in this context. Each practice is categorized
with a specific problem statement that the practice can directly target to solve and
provide additional data to help you to decide on using the practice.
Note: If you are getting into the Defect Fix phase, you may want to adopt any / all of
the below practices, but if you are already in the defect fix phase, I would
recommend you start with Defect Retrospective (practice no. 5) to know the trend
and choose the right practice.
Development
Lead
Developer Continuous
Build
1b
machine
Internal
Tester
This practice initially appears to consume longer time period, but if you trace back
the reason for defect re-opening it could be due to the oversight in unit testing and
functional (mis)understanding. It will be a worthy effort and in due course of time
and, the development team will soon be accustomed to the practice.
Suggestion: Chose the best person with domain knowledge for the internal tester
role.
2. Defects Stand-ups
Problem Addressed: Lack of prioritization on defects and defects fix span across
multiple vendors.
Solution description: This is similar to the daily stand-up with a specific focus on
defects. The questions asked in the meet could be:
• What are the defects that you fixed from yesterday till today? (defect – id and
description)
• What are the defects that you are planning to fix today? (validate the priority)
• Are there any issues that prevent you from fixing the defects?
Suggestion: Update the defect- tracking tool with the details after the stand-up.
Solution description: The worst situation you may want to be in is to have a very-
busy testing team and not-so-busy development team. It is absolutely important to
work very closely with the development team if you are expecting considerable
amount (100, 200 or say 1000) of defects.
• Organize your development team in shifts (to enable fix round the clock
defects)
Actual Closure
Planned Open
Closure Plan
Actual Open
Raised
Open
Date n+1
Date n
Date n - 1
• Date column: The latest date will be recorded as the first entry (insert a new
row at the top)
• The ‘During the day’ section tracks the defects fix velocity – defects fix/day. It
can be used to measure the testing velocity as well
• The ‘Close of the Day’ section tracks the development team’s ability to
maintain the velocity by tracking themselves towards planned and actual
closure
It may look bit complex, but once implemented you can experience good and
productive results.
Suggestion: Leverage the test manager to update the template and circulate
4. Defect Scrum
Problem Addressed: Too many design Issues or requirement gaps.
Solution description: This is very relevant while you encounter with critical or
showstopper defects, which are marked as ‘Design Issue’ or ‘Requirement Gap’. You
need to pay special attention and monitor the situation very closely (Defect
Retrospective can help here).
This scenario would require the development and design team to call for a 30
minutes meeting to understand the critical / high defects and agree on the
implementation. The defects scrum needs to be extended to Product Owner /
Business to close the ‘Requirement Gap’.
Suggestion: You need to setup a standard time regularly for defects scrum.
Solution description: Most of the time the defect root cause does not yield valid
details due to the various invalid closure code, sometime the list of closure code
exceeds the count of defects (may be funny but true). This practice deals with
consolidating the defects of all kinds and generating a report on a weekly basis to
look at the split-up of defects by closure codes.
• Take corrective actions to avoid recurring defects – e.g. Identify the reasons
why we have invalid data