Global 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)

Defect Fix Support from

offshore

Developer platform (offshore)

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.

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.
1a

Development
Lead

Developer Continuous
Build
1b
machine

Internal
Tester

1. Developer sends an email to the development lead to review the code

changes.

a. Development lead provides feedback (if any)

b. 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 During the Day Close of Day

of
day
 Currently Open
Fixes provided

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.

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.