Global Agile Delivery Model: Agile Practices in Integration and System Integration Testing Phase

 

I am sure most of us have gone through a rough development phase during which we would have thought if it is good to implement agile methodology in development. It is very disheartening to see our favorite project being trapped in the testing phase with never ending loop of defect fixes and disrupting the whole idea of agile delivery model in the defect fix phase.

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)

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.

1. Defects (Fix) Showcase

Problem Addressed: Too many re-opened defects

Solution description: 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 email to the development lead to review the code changes.
   1. Development lead provides feedback (if any)
   2. Development lead sends an approval email on the code
2. Development sends an email 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 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?

It is on such discussions/meetings we would realize a surprising factor that more than one person would be working on a same defect or someone will be working on a defect that is considered as closed (may be funny but true).

Suggestion: Update the defect- tracking tool with the details after the stand-up.

3. Defect (Daily) Iteration

Problem Addressed: Too many defects to manage and it appears as if the development team is not making any progress. Team is not being very productive.

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.

You may need to :

• Organize your development team in shifts (to enable fix round the clock defects)
• Have once a day check-point (preferably mid-day)
• Have the defect closure plan as defined below

Date	Start of day	During the Day	Close of Day
Open	Raised	Fixes provided	Currently Open	Closure Plan	Actual Closure	Planned Open	Actual 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.

5. Defects (Fix) Retrospective

Problem Addressed: Eliminate unwanted closure codes.

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.

This will help you to ensure:

• All defects are closed with a valid closure codes
• Grouping of closure codes to provide meaningful actions – e.g. Invalid data, corrupt data, wrong data can be classified to Invalid Data
• Take corrective actions to avoid recurring defects – e.g. Identify the reasons why we have invalid data

Suggestion: See if this process of report generation can be automated.