By Vetrivel Shanmugasundaram
Integration Testing Phase
I am sure most of us have gone through a rough development phase during which we would have considered implementing agile methodology. It is very disheartening to see our favorite project being trapped in the testing phase with a never ending loop of defect fixes and disrupting the whole idea of an agile delivery model.
The defects fix phase starts as the development team completes the coding and unit testing, and moves the code to the integration testing and/or system integration testing phase (Please refer to the figure below)
This phase is very crucial because 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 to a “lack of design time,” refer to an e-mail chain, or worst case, compromise on their software engineering practices to do a “quick-fix.” Traditionally, software development vendors may trim the size of the development team during the development support phase, which does not help either.
If that is the problem, then what is the solution? Frankly, there is no “one” solution to the problem. I have tried to present a set of best practices based on my experience that will help us address this issue. I’ve included a few example problems; each is paired with a best practice that can help address the problem. I have also included additional information to help you decide on the best course of action.
Note: If you are just entering 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 the Defect Retrospective (practice no. 5) to better understand the trend and choose the right practice.
1. Defects (Fix) Showcase
Problem: Too many re-opened defects
Solution: This practice would enable the development team to demonstrate the defect fixes to an internal tester (can be another developer) using the developer test cases. The internal tester also runs through the developer test cases and validates the results. Therefore, the concern actually repeats the tests in the development environment independently.
1. Developer sends an e-mail to the development lead to review the code changes.
a. Development lead provides feedback (if any)
b. Development lead sends an approval e-mail on the code
2. Development sends an e-mail to internal tester (another developer) for a defect fix demo.
3. Internal tester reviews the defect fix and approves it.
4. Developer checks in the code on continuous build server.
This practice initially appears to consume more time, but a defect re-opening could be due to an oversight in unit testing and a functional (mis)understanding. It will be worth the time and effort, and the development team will soon be accustomed to the practice.
Suggestion: Choose the best person with domain knowledge for the internal tester role.
2. Defects Stand-ups
Problem: Lack of prioritization on defects and defects fixes span across multiple vendors.
Solution: This is similar to the daily Scrum, with a specific focus on defects. The questions asked in the meeting could be:
- What defects have you fixed from yesterday to today? (defect – id and description)
- What defects are you planning to fix today? (validate the priority)
- Are there any issues that prevent you from fixing these defects?
During these discussions/meetings we could discover that more than one person is working on the same defect or that someone is working on a defect that is considered closed.
Suggestion: Update your defect- tracking tool after the stand-up.
3. Defect (Daily) Iteration
Problem: Too many defects to manage, and the development team is not making any progress. Team is not being very productive.
Solution: A worst case scenario involves a very busy testing team and a not-so-busy development team. It is absolutely important to work very closely with the development team if you are expecting a considerable amount (100, 200 or say 1000) of defects.
You may need to :
- Organize your development team in shifts (to enable 24-hour fixing)
- Have a daily progress review (preferably mid-day)
- Use a defect closure plan as defined below
- 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 as defects fixed per 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 complex, but once implemented you can experience good and productive results.
Suggestion: Leverage the test manager to update and circulate the template
4. Defect Scrum
Problem: Too many design Issues or requirement gaps.
Solution: This is relevant while you deal 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 (a Defect Retrospective can help here).
This scenario would require the development and design team to arrange a 30 minute meeting to understand the critical defects and agree on the implementation. The defects Scrum needs to include the Product/Business Owner to close the "Requirement Gap."
Suggestion: You need to establish a standard time for a regular Defects Scrum.
5. Defects (Fix) Retrospective
Problem: Unwanted closure codes.
Solution: Often, the defect root cause does not yield valid details due to the various invalid closure code, and sometimes the list of closure code exceeds the count of defects. This practice deals with consolidating defects of all kinds and generating a weekly report to review the spread of defects by closure code.
This will help you to ensure the following:
- All defects are closed with a valid closure code
- Logical grouping of closure codes – e.g. Invalid data, corrupt data, wrong data can be classified as invalid data
- Take corrective actions to avoid recurring defects – e.g. Identify the reasons why we have invalid data
Suggestion: See if this report can be automated.
