A

SUMMER INTERNSHIP REPORT

ON
“A STUDY OF AGILE METHODOLOGY FOR QUALITY OF
SOFTWARE PROJECT AT TATA CONSULTANCY SERVICES”

SUBMITTED BY
NEHA SUSHILKUMAR CHHABADIA
UNDER THE GUIDANCE OF
PROF. SHITAL KALHAPURE

SUBMITTED TO
"SAVITRIBAI PHULE PUNE UNIVERSITY"

IN PARTIAL FULFILMENT OF
MASTER OF BUSINESS ADMINISTRATION (MBA) (BATCH 2017 -
2019)

THROUGH
DNYANSAGAR INSTITUTE OF MANAGEMENT AND
RESEARCH,BALEWADI, PUNE 411045
 DECLARATION

I Neha Sushilkumar Chhabadia student of Dnyansagar Institute of

Management and Research Balewadi, Pune, hereby declare that the project
report entitled as “A STUDY OF AGILE METHEDOLOGY FOR
QUALITY OF SOFTWARE PROJECT AT TATA CONSULTANCY
SERVICES” under the guidance of PROF. SHITAL KALHAPURE,
submitted to “SAVITRIBAI PHULE UNIVERSITY OF PUNE”, for
partial fulfillment of the requirement of the award of M.B.A.

The findings are based on the data collected by myself. The project report is
not poured from any other report and been submitted by me for any other
examination of this university or any other university.

Date: Yours Faithfully,

Place: (Miss. Neha Chhabadia)
 ACKNOWLEGEMENT

I take this opportunity to express my sincere gratitude to all who have directly
and indirectly contributed to the completion of my project.

At the outset of this report I wish to thank the director of our institute
Dr.Sajid Alvi Sir, my sincere thanks to my project guide Prof. Shital
Kalhapure for her constant guidance and support throughout the project. I
would like to thank the placement department and faculty members of DIMR.

I express my deepest gratitude to Mr. Nikhil Thakur who on behalf of the

management of TATA CONSULTANCY SERVICES gave me an
opportunity to complete my Summer Internship Project in the organization.

Lastly I am grateful to my parents who have been my mentors and motivators.

I am also thankful to all my batch mate who have been directly or indirectly
involved in successful completion of this project.

Neha Sushilkumar Chhabadia

MBA 2nd Year
 Table of Contents

CHAPTER
NO. PARTICULARS PAGE NO

1 INTRODUCTION/EXECUTIVE SUMMARY 6

2 OBJECTIVE OF THE STUDY 14

3 COMPANY/ ORGANIZATION PROFILE 16

4 RESEARCH METHODOLOGY 20

5 DATA ANALYSIS AND INTERPRETATION 24

6 RELEVANT ACTIVITIES 44

7 SUGGESTIONS AND RECOMMENDATION 61

8 CONCLUSION 64

9 REFRENCE 67

10 70
APPENDIX
1 Introduction

1.1 Background of the study

Software industry includes many different processes, for example, analysis,

development, maintenance and publication of software. This industry also includes software
services, such as training, documentation, and consulting. So, due to that different types of
projects have different requirements. Therefore, it may be required to choose the right
Software Development Process or Methodology according to the specific needs of the
project. These different requirements and needs give us various software development
approaches to choose from during software implementation.

Types of Software developing life cycles (SDLC)

 Waterfall Model

 V-Shaped Model

 Evolutionary Prototyping Model

 Spiral Method (SDM)

 Iterative and Incremental Method

 Extreme programming

 Agile development

6
1.1.1 Agile Software Development Methodology

Agile software development is a group of software development methods in which

requirements and solutions evolve through collaboration between self-organizing, cross-
Functional teams. Agile Software development Methodology is based on iterative and
incremental development which gives emphasis on following points:

 Individuals and cohesive team over processes and tools

 Working deliverable over documentation

 Customer constant feedback over contract negotiation

 Being flexible with the changes than following a plan

It promotes adaptive planning, evolutionary development, early delivery, continuous

improvement and encourages rapid and flexible response to change.

Figure 1: Agile Software Development Methodology

The Agile Manifesto, which first laid out the underlying concepts of agile development,
introduced the term in 2001.

7
Manifesto for Agile Software Development
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.
Principles behind the Agile Manifesto: (Agile Methodology)

 Customer satisfaction by rapid delivery of useful software

 Welcome changing requirements, even late in development
 Working software is delivered frequently (weeks rather than months)
 Working software is the principlel measure of progress
 Sustainable development, able to maintain a constant pace
 Close, daily co-operation between business people and developers
 Face-to-face conversation is the best form of communication (co-location)
 Projects are built around motivated individuals, who should be trusted
 Continuous attention to technical excellence and good design
 Simplicity
 Self-organizing teams
 Adaptability to changing circumstances

Agile methods break tasks into sub-tasks with minimal or no planning, and keeps a focus on
immediate sprint rather than long-term planning. Iterations are short time frames typically
ranging from one to four weeks. Every iteration involves a team working t hrough a full
software development cycle including planning, requirements analysis, design, coding, unit
testing, and acceptance testing and at the end we have a small piece of software
delivered/demonstrated to stakeholders. This minimizes overall risk as customer is constantly
seeing the progress and providing his feedback which allows the project to adapt to changes
quickly. Stakeholders produce documentation as required. Iteration may not have enough
functionality to do a market release, but the goal is to have an available release (with minimal
bugs) at the end of each iteration. Multiple iterations may be required to release a product or
new features.

8
Figure 2: Agile Software development methodology work flow

Team composition for an agile project is usually cross-functional and self-organizing without
consideration for any existing corporate hierarchy or the corporate roles of team members.
Team members normally take responsibility for tasks that deliver the functionality iteration
requires. They decide individually how to meet iteration's requirements.

Agile methods emphasize face-to-face communication over written documents when the
team is all in the same location. Most agile teams work in a single open office (called a
bullpen), which facilitates such communication. Larger development efforts may be
delivered by multiple teams working toward a common goal or on different parts of an effort.
When a team works in different locations, they maintain daily contact through
videoconferencing, voice, e-mail, etc.

9
1.1.2 Software testing with Agile:

Agile testing is a software testing practice that follows the principles of agile software
development. (Vennapoosa, 2006) Agile testing involves all members of a cross-functional
agile team, with special expertise contributed by testers, to ensure delivering the business
value desired by the customer at frequent intervals, working at a sustainable pace.

Agile development recognizes that testing is not a separate phase, but an integral part of
software development, along with coding. Agile teams use a "whole-team" approach to
"baking quality in" to the software product. Testers on agile teams lend their expertise in
eliciting examples of desired behavior from customers, collaborating with the development
team to turn those into executable specifications that guide coding. Testing and coding are
done incrementally and iteratively, building up each feature until it provides enough value to
release to production. Agile testing covers all types of testing. The Agile Testing Quadrants
provide a helpful taxonomy to help teams identify and plan the testing needed.

1. The combined team, including testing, takes responsibility for analyzing the business
requirements (e.g. user stories). They together define the sprint goal.

2. The QA team defines the testing scope (i.e. test plan). That is then validated by the
whole team and the client.

3. Simultaneously, while the development team starts the implementation, the QA team
begins work on the test case design. These are properly documented and handed over to
the client and the development team for review. This is to ensure the complete test
coverage avoids unnecessary or redundant test cases.

4. QA defines along with the development team and the client which main flows (test
cases) will be automated.

6. When code is deployed and ready to test on QA Environment, QA performs a quick

smoke test on QA environment to make sure code is ready for test.

7. The QA team then begins testing on the QA environment. Any defect at this stage is
again reported. The QA Test Executions cycles may depend on the application under
test but usually it involves System Test and/or System Integration Test followed by
Regression testing

10
 8. At the end of the iteration the team determines, along with the client, which defects are
to be fixed in the current iteration.

1.1.3 Overview of Regression testing

Regression testing is a quality control measure aimed at ensuring the following two
conditions: (J.B.Rajkumar, 2012)

a) Newly modified code meets the specified requirements.

b) Unmodified code has not been affected by the change as above.

As regression testing remains the only reliable means to provide adequate confidence that
changes or additions in the code are safe & are not liable to "break" the existing functionality
of the application; regression testing thus becomes a must, every time code is modified or is
used in a new environment. It is essential to verify the integrity of the code with a view to
identify & fix the defects as quickly as possible.

Objective of regression testing is not only limited to testing the correctness of an application
but extends to track the quality of its output as well. For example, while designing a
compiler, regression-testing can lay focus on the size of the code, time for doing simulation and
time to run the test suites.

11
1.2 Statement of the problem

The Delay in the Code Development impacts the Testing schedule forcing team to reduce the
planned days allocated to System testing and Regression tests. This research is undertaken to
identify the impact of the time crunch on the software testing mainly Regression testing and the
impact on the Quality of the Regression testing in every sprint of the Agile Project.

 The last minute modification of regression test suite reduces the available time for test
execution. This can cause the quality of test execution because of lack of time and dual
mindset.

 At the same time as the tester has to complete the task in insufficient time they tend to
give less importance towards the completeness and correctness of the test cases. This
can also cause certain areas of the test cases to be missing out from getting updated.

 Duplication of efforts in test design: As we have already discussed earlier that the
same business functions are often changed and enhanced multiple times over many
sprints. As we don't have any mechanism in place which can identify the test cases
getting affected by functional enhancements; this causes the test duplication. When
tester starts writing system test cases based on new requirements he tends to
overlook the similar test cases available in regression test suite which is pointing to
the enhanced functionality. Which can be used as system test just by doing little
changes in the test case; thereby reducing the turn-around time.

 Duplication of efforts in test execution: Above mentioned point maximize the chances
of duplication of the test cases in System and Regression test suite. These duplicate
test cases in System test and Regression test pack gets executed twice. At the same time
the regression test case is updated based on the change/ enhancement in the functionality.

 Execution of obsolete test cases: The change/ enhancement in the

functionality can cause some of the regression test cases to be Obsolete tes t case,
As there is no such process to identify the obsolete test cases these test cases becomes
part of the regression test suite. This is identified when the test case is half executed
causing the effectiveness of the tester.

 Key functionality missing from regression pack: The regression pack for iteration
is identified by selecting certain number of test cases from Regression test suite. If
the selection is based on random selection then there can a possibility of missing

12
 key functionality from regression pack. If the test cases are selected on risk based
approach can take longer time to identify the regression pack.

 Loss of time and efforts if any variance found: As per the current approach of
updating regression test case during execution can affect the mindset of the tester
which led them to go back to base line for cross checking of any variance found in the
expected and Actual results. Further it can cause raising invalid defect as the test
case is not updated as per the functionality enhancement.

 Chance of defect slippage: Adding to the above point, if the Regression Pack is not
updated; there is always a chance of defect slippage.

 Bring down the confidence level of tester: All these factors can bring down the
confidence level of the tester in the regression testing

13
 2 Objectives of the Study

1. To analyze of the impact of the development slippage within sprint on testing

activities for Agile Projects
This objective will identify the reasons for code development slippage in sprints and
the fashion in which it occurs for example the delay happens on not and the
percentage of delay.
2. To analyze the Impact of the development slippage on the Regression testi ng.
This objective will identify and analyze if the impact of the delay on the testing
activities

3. To analyze the Impact development slippage on overall product quality in Agile

Projects
This objective will analyze the weather code development delay impacts the final
product quality.

2.1 Scope of the study

This Research will only focus on the Software Development Projects using Agile
Methodology where Regression testing is performed in each sprint.

2.2 Limitations of the study

Limitations are influences that the researcher cannot control. They are the shortcomings,
conditions or influences that cannot be controlled by the researcher that place restrictions on
your methodology and conclusions. The limitations that might influence the results are
mentioned below:

The study is only considering the Projects which were delivered on Agile methodology only
and most of the project uses tailored agile methodology which means no projects was using
pure agile development and the there may be process difference in the methods which may
impact the project study.

14
2.3 Significance of the study

Significance to Industry:

The contribution of this study would be of interest to the Agile projects currently facing
Development delay issues and it will help them with some best practices which can
reduce the impact of the delay of the code deployment on the overall project quality.

Significance to my personal development:

Working on this Project was a great learning experience. Following were the key points where
researcher has to put more efforts during this work:

 Identifying a Problem Statement

 Formulating Problem statement

 Generalizing Problem statement

 Gain deeper understanding of the Software Development Methodology and the
Process followed in the Organization in implementing the same.
 Identifying Solution for the Problem Statement.

 Study the different Methodology for Report.

 Evaluating Solution

15
3 ABOUT COMPANY:-

3.1 TATA CONSULTANCY SERVICES

Tata Consultancy Services Limited (TCS) is an Indian multinational information technology
(IT) service, consulting and business solutions company headquartered in Mumbai,
Maharashtra.
It is a subsidiary of the Tata Group and operates in 46 countries.
TCS is one of the largest Indian companies by market capitalization. TCS is now placed
among the most valuable IT services brands worldwide. TCS alone generates 70% dividends
of its parent company, Tata Sons. The parent group recently decided to sell stocks of TCS
worth $1.25 billion in a bulk deal. In 2015, TCS is ranked 64th overall in the Forbes World's
Most Innovative Companies ranking, making it both the highest-ranked IT services company
and the top Indian company. It is the world's 9th largest IT services provider by revenue. As
of 2017, it is ranked 10th on the Fortune India 500 list. In April 2018, TCS became the first
Indian IT company to breach $100 billion market capitalization, and second Indian company
ever (after Reliance Industries achieved it in 2007) after its m-cap stood at Rs 6,79,332.81
crore ($102.6 billion) in Bombay Stock Exchange.
On 12 January 2017, N.Chandrashekaran was elevated as the chairman for Tata Sons.
TCS Limited was founded in 1968 by division of Tata Sons Limited. Its early contracts
included punched card services to sister company TISCO (now Tata Steel), working on an
Inter-Branch Reconciliation System for the Central Bank of India, and providing bureau
services to Unit Trust of India.
In 1975, TCS delivered an electronic depository and trading system called SECOM for
the Swiss company SIS SegaInterSettle (deutsch); it also developed System X for the
Canadian Depository System and automated the Johannesburg Stock Exchange. It associated
with a Swiss partner, TKS Teknosoft, which it later acquired.
In 1980, TCS established India's first dedicated software research and development center,
the Tata Research Development and Design Centre (TRDDC) in Pune. In 1981, it established
India's first client-dedicated offshore development center, set up for clients Tandem. TCS
later (1993) partnered with Canada-based software factory Integrity Software Corp, which
TCS later acquired.
In anticipation of the Y2K bug and the launch of a unified European currency (Euro), Tata
Consultancy Services created the factory model for Y2K conversion and developed software
tools which automated the conversion process and enabled third-party developer and client

16
implementation. Towards of end of 1999, TCS decided to offer Decision Support System
(DSS) in the domestic market under its Corporate Vice President and Transformation Head
Subbu Iyer.
On 25 August 2004, TCS became a Publicly Listed Company.
In 2005, TCS became the first India-based IT services company to enter
the bioinformatics market. In 2006, it designed an ERP system for the Indian Railway
Catering and Tourism Corporation. By 2008, its e-business activities were generating over
US$500 million in annual revenues.
TCS entered the small and medium enterprises market for the first time in 2011, with cloud-
based offerings. On the last trading day of 2011, it overtook RIL to achieve the highest
market capitalization of any India-based company. In the 2011/12 fiscal year, TCS achieved
annual revenues of over US$10 billion for the first time.
In May 2013, TCS was awarded a six-year contract worth over ₹ 1100 cores to provide
services to the Indian Department of Posts. In 2013, the firm moved from the 13th position to
10th position in the League of top 10 global IT services companies and in July 2014, it
became the first Indian company with over Rs 5 lakh core market capitalizations.
In Jan 2015, TCS ends RIL's 23-year run as most profitable firm
In Jan 2017, the company announced a partnership with Aurus, Inc., a payments technology
company, to deliver payment solutions for retailers using TCS Omni Store, a first of its kind
unified store commerce platform.
TCS and its 67 subsidiaries provide a wide range of information technology-related products
and services including application development, business process outsourcing, capacity
planning, consulting, enterprise software, hardware sizing, payment processing, software
management and technology education services. The firm's established software products
are TCS Bancs and TCS Master Craft.

17
3.2 Service lines

TCS' services are currently organized into the following service lines (percentage of total
TCS revenues in the 2017-18 fiscal year generated by each respective service line is shown in
parentheses):
Asset leverage solutions (2.70%);
Assurance services (7.70%);
Business process outsourcing (12.50%);
Consulting (2.00%);
Engineering and Industrial services (4.60%);
Enterprise solutions (15.21%); and
IT infrastructure services (11.50%).
Application development and maintenance (43.80%) value;

3.3 Tata Research Development and Design Centre

TCS established the first software research center in India, the Tata Research Development
and Design Centre, in Pune, India in 1981. TRDDC undertakes research in Software
engineering, Process engineering and systems research. Researchers at TRDDC also
developed MasterCraft (now a suite of digitization and optimization tools)a Model Driven
Development software that can automatically create code based on a model of a software, and
rewrite the code based on the user's needs. Research at TRDDC has also resulted in the
development of Sujal, a low-cost water purifier that can be manufactured using locally
available resources. TCS deployed thousands of these filters in the Indian Ocean
tsunami disaster of 2004 as part of its relief activities.This product has been marketed in India
as Tata swach, a low cost water purifier.

18
3.4 Employees

TCS is one of the biggest and the largest private sector employers in India, and the fourth-
largest employer among listed Indian companies (after Indian Railways, Indian Army and
India Post).TCS had a total of 387,000 employees as of December 2017, of which 31% were
women. The number of non-Indian nationals was 21,282 as at 31 March 2016 (7.7%). The
employee costs for the FY 2017-18 were US$4.38 billion, which was approx. 38% of the
total revenue of the company for that period. In the fiscal year 2017-18, TCS recruited a total
of 69,728 new staff, of whom 59,276 were based in India and 10,452 were based in the rest of
the world. In the same period, the rate of attrition was 10.6%.The average age of a TCS
employee is 28 years. The employee utilization rate, excluding trainees, for the FY 2012-13
was 82%.TCS was the fifth-largest United States visa recipient in 2008
(after Infosys, CTS, Wipro and Mahindra Satyam). In 2012, the Tata group companies,
including TCS, were the second largest recipient of H-1B visas. As of June 2017, TCS has
over 387,000+ employees. It is world's third largest IT employer behind IBM and HP.
Subramaniam Ramadorai, former CEO of TCS, has written an autobiographical book about his
experiences in the company called The TCS Story...and Beyond.

19
4 Research Methodology
Research Methodology is the process used to collect information and data for the
purpose of making business decisions. The methodology includes publication research,
interviews, surveys and other research techniques, and could include both present and
historical information.

4.1 Research design

A descriptive research methodology was used for this study. A survey was administered
to a selected sample from a specific population identified in Testing Projects. The term
'survey' is commonly applied to a research methodology designed to collect data from a
specific population, or a sample from that population, and typically utilizes a
questionnaire or an interview as the survey instrument. Sample surveys are an
important tool for collecting and analyzing information from selected individuals

4.2 Sources of data

Due to the complexity of the research topic and questions, it was decided to use
Interview using closed loop questionnaire. This research study used quantitative data
for analyzing the objectives and proving the Hypothesis mentioned in the introduction.

4.2.1 Primary Research Data

For the study the primary data was collected using Interviews. Potential respondents were
given an identical array of closed questions in a set order about their experience working
Regression testing on Agile Project.

a. Interview Questionnaire

 The questionnaire was prepared covering following areas of software

testing: - The current state of the project
 The Project schedule adherence
 Impact of delay on Regression testing

20
All the questions are closed loop questions however Interviewing has allowed to capture
additional descriptive information which can be used in the conclusion.

For this study we have framed the 24 number of questions under the head of above sub
topics. Every topic is been analyzed separately as part of this research.

Mapping of the Questions against the Objective and Hypothesis of the Research:

Question No Objective 1 Objective 2 Objective 3

1a, b & c - - -
2 - - -
3 - - -
4 - - -
5 - - -
6 Yes
7 Yes
8 Yes
9 Yes
10 Yes
11 Yes
12 Yes
13 Yes
14 Yes
15 Yes Yes
16 Yes
17 Yes
18 Yes
19 Yes
20 Yes
21 Yes
22 Yes Yes
23 Yes
24 Yes

21
b. Respondents
The respondents for this study are:
 Team Leaders
 Scrum Masters
 Project Leads
The Respondents selected were from different Software Development Projects that
are using Agile Methodology.

c. Sampling

Considering the size of the Population (45 Projects) complete using Agile Methodology in
Target Company the Interview was planned with Representative like team Leaders or Scrum
Masters from Sample of 10 different Software Development Projects using Agile
Methodology. During the Interview the Questionnaire was shared with the respective
ProjectRepresentative and we explained them with the objective of the study. The Project
used for the sampling were using Manual as well as Automation testing approach for
Regression testing and were performing Regression testing in every sprint.

4.2.2 Secondary Research Data

Secondary data was collected from different sources like web sites, papers journals, word of
mouth etc. The use of secondary data was important, but it cannot be considered as valid and
conclusive as the primary data. This data was mainly used for generating the questionnaire
and used as an argument about the significance of the research.

4.3 Methods of data collection

The data has been collected runtime during the interview with the Sample Project
stakeholders. As part of the interview a questionnaire are be filled on Printed Paper and then
the same would be feed into the system for analysis.

22
4.4 Methods of Analysis

Data collected from the different sample data is been captured and presented in tabular
format and the Impact of the Delay in the Code Development on Regression Testing is
analyzed in terms of the projects facing the issues raised due the delay.

23
5 Presentation and analysis of data

Based on the response received during the interview we analyzed the answers and observed
following observations:

5.1.1 Approximate/Average Length of one Iteration/Sprint (In weeks)

The length of the sprint is important as part of this study as it reflects the number of days
available for all the development activities. If the Sprint is short the time available is very
less for all the testing and development activity and any issue in any of the activity may
impact the whole sprint schedule.

The Sample data selected for the study has short to long sprints. 60% of the sample projects
were identified as having 2 weeks of a sprint.

Approximate/Average Length of one Iteration/Sprint? (in weeks)

Time
Frame 1 week 2 weeks >2 weeks
Projects 2 6 2

Approximate/Average Length of one

Iteration/Sprint (in weeks)

20% 20%
1 week
2 weeks
>2 weeks

60%

Graph 1: Approximate/Average Length of one Iteration/Sprint (In weeks)

24
5.1.2 Regression Test cases are automated.

Regression Test Automation helps projects in regression test execution over night reducing
the regression time drastically compared to manual testing. However Automation Regression
testing required high Maintenance in terms of keeping the scripts up to date for execution.

The Sample data selected has mixed projects as captured in the table below:

Automated Regression Test

Response Yes No Partly
Projects 1 6 3

Automated Regression Test

10%
30%

Yes
No
60% Partly

Graph 2: Projects with Automated Regression Tests from the sample projects selected

25
5.1.3 Delays Observed in Development.

More than 60% of projects observed the delays happened in Code Development within the sprint
doe to some or the other reasons including internal and/or external factors. This delay is on top of
the buffer time kept for the development and defect fixing.

Observed Delays in Development

Response Yes No Some Times
Projects 6 1 3

Observed Delays in Development

30%

Yes
60% No
10%
Some Times

Graph 3: Projects impacted by Code development delays

26
5.1.4 Delay in % Development time

Out of 10 projects 40% of the projects observed delay greater than 20% of development time
and 50% of projects observed delay less than 20% of development time. This means, if the
development estimation is 5 days, the development has taken additional day or 2 to complete
the deployment in 50% of the project. This is then translated to the reduction in the test
execution time by same time causing 1-2 days less than the original estimate.

Delay in % Development time

Response 0% <= 20% > 20%
Projects 1 5 4

Delay in % Development time

10%
40%

0%
<= 20%
50%
> 20%

Graph 4: Delay in the sprint development

27
5.1.5 Reasons for the Delay

There are various reasons of delay observed but the most common are the once which are
captured in the questionnaire. There are internal and external factors impacting the
development schedule. We have considered only internal factors for the research
questionnaire. 50% of the development delay is observed due to the due to the initial
understanding of the User Story and Assumptions/clarifications and impediments of the same
or over commitment from the team. It is observed that 40% of development delay is due to
improper sprint planning may be due to lack of knowledge of the functionality under scope or
functionality not properly analyzed before planning which increased the development efforts
within the sprint.
Probable Reasons for the Code Deployment Delay
Response No Delay Complexity in the Requirement Sprint Planning
Projects 1 5 4

Probable Reasons for the Code

Deployment Delay

10%
40% No Delay

Complexity in the
50% Requirement
Sprint Planning

Graph 5: Probable Reasons for the Code Deployment Delay

28
5.1.6 Impact of the delay on the estimated testing time Observed

As discusses the delay in the Development has reduced the estimated test execution time.
70% of the projects were impacted by the development delay reducing available time for
testing. However at the same time for most of the projects the sprint dead line is not increases
which will be discussed in the further questions.
Impact of the delay on the estimated testing time
Response Yes No Some Times
Projects 7 1 2

Impact of the delay on the estimated

testing time

20%

10% Yes
No
70%
Some Times

Graph 6: Impact of the delay on the estimated testing time

29
5.1.7 What is Test Execution time reduction in Sprint against actual Planned Time

It is observed that the delay in the code development has impacted almost 90% of the projects
resulting in more than 20% of time reduction in the estimated test execution time. As discussed earlier
for the delay by 1-2 days in the development estimation reduced the same number of days from
testing cycle impacting testing activities.

Functional testing time reduction observed

Response <20% 20 to 30% >30%
Projects 3 5 2

Functional testing time reduction

observed

20% 30%

<20%
20 to 30%

50% >30%

Graph 7: Functional testing time reduction

30
5.1.8 Getting Change Requests frequently within the sprint

When asked if the project expect the change request with in the sprint the answer from most of the
project is yea as Agile promotes the CR any time in the sprints. 90% of the projects observed the
Change Requests and they have accepted the change within the same sprint. This change usually
impacts the scope of the development and testing impacting the sprint estimate.

Change Requests Frequency within the sprint

Response Yes No Some Times
Projects 5 1 4

Change Requests Frequency within

the sprint

40%
50% Yes
No

10% Some Times

Graph 8: Change Requests Frequency within the sprint

31
5.1.9 Schedule extension for Regression testing

It is observed that not all the projects get schedule extension for the increased in the scope of
the testing due to the change request which means the development and testing has to be fit
into the given time resulting in delay in both development and testing activity. For which
both the teams need to stretch and try and complete related activities in given time. Only 20%
of the projects get the required extension however the same is not sufficient to accommodate
the change.

Additional Time for Regression testing

Response Yes No Some Times
Projects 2 5 3

Additional Time for Regression

testing

30% 20%

Yes
No

50% Some Times

Graph 9: Additional Time for Regression testing

32
5.1.10 Time to update and maintain the Regression test Pack.

For regression test completeness it is important the regression tests are maintained over the
sprints. It is observed that only 40% of the projects do this activity and 60% does not
primarily due to the unavailability of time for this activity.

Update and maintain the Regression test Pack in every Sprint

Response Yes No Some Times
Projects 4 6 0

Update and maintain the Regression

test Pack in every Sprint
0%

40%
Yes
60% No
Some Times

Graph 10: Projects update and maintain the Regression test Pack in every Sprint

33
5.1.11 When do you update the impacted Regression test

The last minute modification of regression test suite reduces the available time for test
execution. This can cause the quality of test execution because of lack of time and dual
mindset. 60% of the projects update the regression tests during the execution. At the same
time as the tester has to complete the task in insufficient time they tend t o give less
importance towards the completeness and correctness of the test cases. This can also cause
certain areas of the test cases to be missing out from getting updated.

Update the impacted Regression test

Response During Planning During Execution Free Time
Projects 2 5 3

Graph 11: when do Projects update the impacted Regression test

34
5.1.12 Duplication observed of efforts in test design?

As we have already discussed earlier that the same business functions are often changed and
enhanced multiple times over many sprints. As we don't have any mechanism in place which
can identify the test cases getting affected by functional enhancements; this causes the test
duplication. When tester starts writing system test cases based on new requirements he tends to
overlook the similar test cases available in regression test suite which is pointing to the
enhanced functionality. This can be used as system test just by doing little changes in the test
case.
Observed duplication of efforts in test design
Response Yes No Some Times
Projects 4 4 2

Observed duplication of efforts in

test design

20%
40%
Yes
No
40% Some Times

Graph 12: Observed duplication of efforts in test design

35
5.1.13 Project impacted by Duplication of efforts in test Execution

Above mentioned point maximize the chances of duplication of the test cases in System and
Regression test suite. These duplicate test cases in System test and Regression test pack gets
executed twice. At the same time the regression test case is updated based on the change/
enhancement in the functionality.

Impact by Duplication of efforts in test

Response Yes No Some Times
Projects 4 3 1

Impact by Duplication of efforts in

test

13%

50% Yes
37% No
Some Times

Graph 13: Projects impacted by Duplication of efforts in test Execution

36
5.1.14 End up in executing obsolete test cases

The change/ enhancement in the functionality can cause some of the regression test cases to be
Obsolete test case, As there is no such process to identify the obsolete test cases these test cases
becomes part of the regression test suite. This is identified when the test case is half executed
causing the effectiveness of the tester.

Executing obsolete test cases

Response Yes No Some Times
Projects 4 2 4

Executing obsolete test cases

40% 40%

Yes
No
Some Times
20%

Graph 14: Projects executing obsolete test cases

37
5.1.15 Reducing Regression test count in Crunch Time.

When the required test execution is not available most of the projects tend to follow risk based
approach and reduce the number of test cases from the regression testing. It is observed that 80% of
the projects reduce the regression test count to fit the testing in given timescale.

Reduction in Regression test count in Crunch Time

Response Yes No Some Times
Projects 4 2 4

Reduction in Regression test count in

Crunch Time

40% 40%
Yes
No
Some Times
20%

Graph 15: Projects Reduce Regression test scope

38
5.1.16 Eliminating the Regression tests

When reduction of the regression count is the only option 40% of teams use risk based
approach where the tests are prioritized and High Priority tests are executed. However it is
observed that 40% of the projects use random selection approach which may result in
missing important tests for the regression test suite.

Regression tests elimination

Response Random Risk Based Execute All
Projects 4 4 2

Regression tests elimination

20%
40%

Random
Risk Based
40% Execute All

Graph 16: Approach for Regression tests elimination

39
5.1.17 observed the Key functionality missing from regression pack do to the test scope
reduction

The regression pack for iteration is identified by selecting certain number of test cases from
Regression test suite. If the selection is based on random selection then there can a possibility
of missing key functionality from regression pack. If the test cases are selected on risk based
approach can take longer time to identify the regression pack.
Key functionality missing from regression pack due to the test scope reduction
Response Yes No Some Times
Projects 4 2 4

Key functionality missing from

regression pack due to the test scope
reduction

Yes
No
Some Times

Graph 17: Projects impacted by missing Key functionalities

40
5.1.18 Time Spent and efforts if any variance found

As per the current approach of updating regression test case during execution can affect the
mindset of the tester which led them to go back to base line for cross checking of any
variance found in the expected and Actual results. Further it can cause raising invalid defect
as the test case is not updated as per the functionality enhancement.

Waste of time and efforts if any variance found due to absolute or out dated tests
Response Yes No Some Times
Projects 3 2 5

Waste of time and efforts if any

variance found due to absolute or out
dated tests

30%
50% Yes
No
20%
Some Times

Graph 18: Projects impacted by absolute Tests

41
5.1.19 observed Defect slippage due to insufficient Regression testing

Adding to the above point, if the Regression Pack is not updated; there is always a chance of
defect slippage which may be due to missing important or impacted Regression tests from the
pack. It is observed that 50% of the projects are impacted some or other time due to this
issue.

Defect slippage due to insufficient Regression testing

Response Yes No Some Times
Projects 2 5 3

Defect slippage due to insufficient

Regression testing

30% 20%

Yes
No

50% Some Times

Graph 19: Projects impacted by Defect slippage

42
5.1.20 observed the impact on the confidence level of tester when executing the tests
which are not up to date

All these factors can bring down the confidence level of the tester in the regression testing. It
is observed that almost 70% of the projects are faces this issue some or other time during the
project in past.

Confidence level of tester when executing outdated test cases

Response Yes No Some Times

Projects 2 5 3

Confidence level of tester when

executing outdated test cases

30% 20%
Yes
No
50% Some Times

Graph 20: Impact on the confidence level of tester

43
6 Relevant Activities
The purpose of this literature review is to examine the existing literature to determine if there are
sufficient evidences on issues and challenges in agile software development slippage in
particular, in Scrum. This requires a review of the literature related to the evolvement of
software development methods.

First Section describes the Software development Methodology and illustrates the
development lifecycle of the waterfall method. This section of the literature review also
includes the shortcomings of the waterfall method and the research results of the Standish
Group on projects conducted with traditional software development methods. Second
Section Describes Agile Software development Methodology and reviews the Manifesto for
Agile Software Development and the principles behind the Agile Manifesto. It includes a
review of discriminators between traditional methods and agile methods. It also reviews the
agile methods for large-scale projects. This section concludes with a review of a comparison
between traditional and agile methods on their characteristics, strengths, and weaknesses.
This section also includes a framework of Scrum and concludes with flow of the Scrum
method. Third Section Describes the Software testing in Agile environment which includes
different Testing activities performed as part of testing. Fourth Section Describes the Code
Deployment Delays in the Agile Software development Methodology; it also reviews the
reasons for the delay in development. Fifth Section describes the impact of the Development
slippage on the Software testing activities focusing more on regression testing and the quality of
the product.

44
6.2 Software development Methodology

Many software development methods that control a software development project have
evolved. One well-known TSDM is the Waterfall model, which utilizes a structured and
sequential progression between defined phases: planning, analysis, design, implementatio n,
and maintenance. According to Dennis, Wixonm, and Tegarden (2005), the planning phase,
which occupies typically about 15% of the total Systems Development Life Cycle (SDLC), is
the fundamental process to identify the scope of the new system, understand why a system
should be built, and how the project team will go about building it through technical,
economical, and organizational feasibility analyses. The analysis phase, about 15% of the
SDLC, analyzes the current system, its problems, and then identifies ways to design the new
system through requirements gathering. The design phase, 35% of the SDLC, decides how the
system will operate in terms of hardware, software, and network infrastructure. The
implementation phase occupies about 30% of SDLC and is the phase where actual coding
occurs. The maintenance phase occupies the remaining 5% of SDLC and focuses on going-live,
training, installation, support plan, documentation, and debugging. Figure 1 and Table 1
Below show a typical waterfall lifecycle and deliverables, respectively. As we can see in the
figure and the table, each phase must be accomplished before the following phase can begin and
each phase cannot go back to the previous phase just as water in the waterfall cannot climb up
once it reaches a lower position.

Figure 4 Waterfall software development Model.

45
Over the past four decades, traditional waterfall-style software development methods have
been widely used for large-scale projects in the software industry and in the government
sector due to their straightforward, methodical, and structured nature as well as their
capability to provide predictability, stability, and high assurance (Boehm & Turner, 2003;
Fruhling & De Vreede, 2006). However, TSDMs have a number of key shortcomings,
including slow adaptation to constantly changing business requirements, and a tendency to be
over budget and behind schedule with fewer features and functions than specified (Boehm,
2002; Boehm & Turner, 2003; Brooks, 1995; Schach, 2004; Sommerville, 2004; Watson,
Kelly, Galliers, & Brancheau, 1997). The conventional methods also have failed to provide
dramatic improvements in productivity, reliability, and simplicity (Brooks, 1995). Boehm
and Philip (1988), and Jones (1997), reported that during their proj ect development
experience, requirements often changed by 25% or more. Williams and Cockburn (2003) also
mentioned that TSDMs were not initially designed to respond to requirements change
occurring in the middle of the development process. They also mentioned that the ability to
take appropriate action in response to a change often determines the success or failure of a
software product. One interesting research study conducted by the Standish Group regarding
8,380 projects from 365 respondents representing companies across major industry segments,
shows that only a small percentage of projects (16.2%) with traditional methods were
Completed on-time and on-budget with all features and functions specified. However, 52.7%
of the projects were completed over-budget, over the time estimate, and/or offering less
features and functions; 31.1% of projects were canceled at some point during the
development cycle (Standish Group, 1994). Figure 3 displays the result of the research. A
more recent study by the same group (Standish Group, 2001) still showed only 28 percent of IT
projects were completed on time, on budget and with all the features and functions
originally specified. Further, the study found that 23% of the projects failed and 49% of the
projects were challenged.

46
 16%

Project Succeeded
53%
31% Project Failed
Project Challenged

Figure 5 Project resolutions.

To address some of the traditional methods' shortcomings, agile methods have been proposed
(Highsmith & Cockburn, 2001). The next section explains the characteristics and principles
of agile software development methods.

47
6.3 Agile Software Development Methods

6.3.1 Overview of Agile Methods

As a remedy for the traditional software development methods' shortcomings, agile software
development methods (ASDMs) were developed. The movement to ASDMs started in the
mid-1990s, by many practitioners in parallel, in different languages, different locations, and
different project contexts (Leffingwell, 2007). William and Cockburn (2003) mentioned that
eXtreme Programming (XP), Scrum, Crystal, and Adaptive Software Development (ASD)
were developed in the U.S. by Ken Beck and Eric Gamma, Ken Schwaber and Jeff
Sutherland, Alistair Cockburn, and Jim Highsmith, respectively. Dynamic Systems
Development Method (DSDM) is a well-documented agile method created by a European
consortium of companies and was commercially adopted in Europe (Leffingwell). Feature
Driven Development (FDD) was developed in Australia and has contributed to the scaling of
agile methods.

The nutshell of ASDMs can be summarized as iterative and incremental development,

adaptability throughout the systems development life cycle, minimal 13 planning, light and
fast development cycles, people-centric development, customer collaboration, and frequent
delivery. In 2001, seventeen practitioners met at Snowbird, Utah, to discuss if there was
anything in common among the various agile methods (Cockburn, 2007), and they created
the Manifesto for Agile Software Development (Beck et al., 2001), which revealed what
items were considered valuable by ASDMs. As shown in Table 3, ASDMs concentrate

1. more on individuals and interactions than processes and tools,

2. more on working software than comprehensive documentation,
3. value customer collaboration more than contract negotiation, and

4. Focus more on responding to change than following a plan.

48
Principles Behind the Agile Manifesto (Source: Beck et al., 2001)

1. Our highest priority is to satisfy the customer through early and

continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple
of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily through the
project.
5. Build projects around motivated individuals. Give them the environment
and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.
7. Workin g so ftware is the primary measure of pr o gress.
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and good design enhances
agility.
10. Simplicity—the art of maximizing the amount of work not done—is
essential.
11. The best architectures, requirements and designs emerge from self-
organizing teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.

49
Agile Methods for Large-Scale Projects

Most agile methods have primarily been applied to small to medium size projects such as
internet and web-based information systems. It is not clear if agile methods are used on large-
scale projects that they can provide end-users with the desired quality in a timely manner
(Marrington, Hogan, & Thomas, 2005). However, some researchers have reported that large-
scale and complex projects have benefited from suitably tailored agile development methods
(Bowers, May, Melander, Baarman, & Ayoob, 2002; Lippert et al., 2003; Cao, Mohan, Xu,
& Ramesh, 2004; Lindvall et al., 2004). Bowers et al. (2002) examined whether the XP
method can handle large-scale and life-critical software systems. The authors adopted the XP
method to redesign their public safety communication systems, which consists of over a
million lines of C language code.

The Philosophical Roots of Scrum

The Scrum software development method is an agile process that can be used to manage and
control complex software and product development using iterative and incremental practices
(Advanced Development Methods, 2009; Schwaber, 2004, 2007, 2008; Schwaber & Beedle,
2002) and is an enhancement of the iterative and incremental approach to delivering
objected-oriented software (Schwaber, 1996). Leffingwell (2007, p. 41) also defined the
Scrum method as ". . . a lightweight agile project management method based on small,
empowered, self-organizing teams; complete visibility; and rapid adaptation." The origin of
term scrum came from the popular sport rugby, in which fifteen players on each team
compete against each other. While the term scrum refers to the strategy used for getting an
out-of-play ball back into play in rugby, it was first used to describe hyper-productive
development processes in Japan (Takeuchi and Nonaka, 1986). Three strategies from rugby,
including a holistic team approach, constant interaction among team members, and
unchanging core team members, are adopted into Scrum's management and control
processes. Takeuchi and Nonaka (1986, p. 137) noted: This new emphasis on speed and
flexibility calls for a different approach for managing new product development. The
traditional sequential or 'relay race' approach to product development — exemplified by the
National Aeronautics and Space Administration's phased program planning (PPP) system —
may conflict with the goals of maximum speed and flexibility. Instead, a holistic or 'rugby'

50
approach — where a team tries to go the distance as a unit, passing the hall back and forth —
may better serve today's competitive requirements. Takeuchi and Nonaka also described six
principles that contribute substantially to the Scrum philosophy. Each principle correlates
directly too many of the principles of the Agile Manifesto that we previously discussed. Their
six principles are

1. built-in instability,
2. self-organizing project teams,
4. overlapping development phases,
5. multi-learning,
6. subtle control, and
7. Organizational transfer of learning.

51
6.4 Software Testing
Definition of testing has varied over the years. Glenford J. Myers initially introduced the
separation of debugging from testing in 1979 in his book The Art of Software Testing as
follows: "Testing is the process of executing a program or system with the intent of finding
errors" (Myers 1979, 6.). As the statement says, the main purpose of testing was finding
errors at the end of development work.

In 1983, Bill Hezel in cluded quality assessment and defined testing in his book The Complete
Guide to Software Testing as follows: "Testing is any activity aimed at evaluating an
attribute of a program or system. Testing is the measurement of software quality". (Hezel
1988, 6, 242.) Testing was as a tool for quality control, and the quality of the delivered
software was the test organization's main responsibility. This approach became inefficient
and expensive, and as developers started to use some tools and techniques to keep the
discipline in code quality, testing was an inevitable expense in software development business.
By the time the significance of testing has increased due to shortened design lifecycles,
decreased time-to market and more complex systems (Belt 2009, 13-14).

Appreciation of testing has been low; thus, no software producer dare deliver software
without testing. Destructive approach to software is inconvenient. Testing is the only role on
the project that does not directly focus on success. Everyone else creates something or
creatively guides its creations. However, testers are negative. This can be a depressing job,
almost like a parody of a Greek myth:"On the island of the testers, they were doomed forever
to search for what could not and should not exist; knowing that to succeed would bring
misery to the Gods." (Bach et al 2002, 151.)

The definition of testing has become more open to consider the multiple dimensions of the
testing. Today it is defined as follows: "We believe great software testing requires
Craftsmanship, Science, and Passion" (Association for Software Testing, 26. November
2011)

52
Testing Cycle
There is a typical cycle for software testing. This sample is useful regardless of the used
development model. The Waterfall model has particular testing phase, the V-model has
grouped the phases according to its development model. In the Agile testing the testers use
these same phases to conduct the testing even if they emphasize certain phases more than
others or some remain invisible.

 Requirements analysis: During the design phase, testers work with developers and
designers to determine what aspects of a design are testable and with what parameters
those tests work.
 Test planning: Test strategy, test plan, test ware creation.
 Test development: Test procedures, test scenarios, test cases, test datasets, test
scripts to use in testing software.
 Test execution: Testers execute the software based on the plans and test documents.
 Test reporting: Testers generate metrics and make final reports
 Test result analysis: Or Defect Analysis, decisions to actions
 Regression testing: Testers execute this in order to ensure that the software product
as a whole is still working correctly.
 Test Closure: Once the test meets the exit criteria.

These phases recur in every planned testing occasion. Such occasion may happen only on the
testers mind, and professional tester recognizes these phases.

53
Agile Testing
Agile testing is a software testing practice that follows the principles of agil e software
development. Agile testing involves all members of a cross-functional agile team, with
special expertise contributed by testers, to ensure delivering the business value desired by the
customer at frequent intervals, working at a sustainable pace. Specification by example is
used to capture examples of desired and undesired behavior and guide coding.

Agile development recognizes that testing is not a separate phase, but an integral part of
software development, along with coding. Agile teams use a "whole-team" approach to
"baking quality in" to the software product. Testers on agile teams lend their expertise in
eliciting examples of desired behavior from customers, collaborating with the development
team to turn those into executable specifications that guide coding. Testing and coding are
done incrementally and iteratively, building up each feature until it provides enough value to
release to production. Agile testing covers all types of testing. The Agile Testing Quadrants
provide a helpful taxonomy to help teams identify and plan the testing needed.

Figure 6 presents a high-level view of the agile lifecycle for the purpose of testing (see
"Initiating an Agile Project" at www.ddj.com/deptiarchitect/188700850 for details). Agile
projects go through an often short Initiation phase (Iteration 0) where we set the foundation
for the project; a Construction phase where we develop the system in an evolutionary
(iterative and incremental) manner; an End Game phase where we transition our system into
production; and a Production phase where we operate the system and support users. Don't
fear the serial boogeyman: The Initiation phase is not a requirements phase, nor is the End
Game a testing phase.

54
Figure 6 Test activities during the agile lifecycle.

Testing activities vary throughout the lifecycle. During Iteration 0, you perform initial setup
tasks. This includes identifying the people who will be on the external "investigative" testing
team, identifying and potentially installing your testing tools, and starting to schedule scarce
resources such as a usability-testing lab if required. If your project has a deadline, you likely
want to identify the date into which your project must enter the End Game. The good news is
that you'll discover that increased testing during construction iterations enables you to do less
testing during the End Game.

A significant amount of testing occurs during construction iterations—remembers, agilists

test often, test early, and usually test first. This is confirmatory testing against the
stakeholder's current intent and is typically milestone-based at the unit level. This is a great
start, but it's not the entire testing picture (which is why we also need investigative testing
that is risk-based at more of an integration level). Regardless of the style, your true goal
should be to test, not to plan to test, and certainly not to write comprehensive documentation
about how you intend to hopefully test at some point. Agilists still do planning, and we still
write documentation, but our focus is on high-value activities such as actual testing.
55
During the End Game, you may be required to perform final testing efforts for the release,
including full system and acceptance testing. This is true if you are legislated to do so
(common in life-critical situations such as medical software development) or if your
organization has defined service-level agreements with customers who require it. Luckily, if
you've tested effectively during the construction iterations, your final testing efforts will
prove to be straightforward and quick. If you're counting on doing any form of "serious
testing" during the End Game, then you're likely in trouble because your team won't have
sufficient time to act on any defects that you do find.

6.5 Delays in Code Development

Delay is anything that causes more time to deliver a value-added activity, or delays the
beginning of the value-added activity.
Possible reasons:

1. Lack of required team members

2. Unwanted processes

3. Too many things in progress

4. External dependencies

5. Lack of "value" understanding

6. Assumptions/clarifications and impediments

56
How can you eliminate it?

1. Make sure you have all the required skill sets assigned to your project. If you start a
sprint without having the required team members with the proper skill sets, this will
lead to delays.

2. Identify only mandatory processes at the beginning of the sprint. For example, if you
do not need to get the code review for all of the code, then categorize the code into
low complex, medium complex, and high complex, and send only medium and high
complex code for review. This will reduce the cycle time and increase efficiency.

3. Keep only what you can handle on your plate and leave the rest open. This will help
other team members pick up the work that's based on their skill sets and bandwidth.

4. Make sure to have all required external assistance available in time for your work. For
example, if you need an external architect review, plan for it up front. Similarly, if
you're working with multiple teams from different locations, then encourage stub-
based development. I have personally observed that when we have videoconferencing
calls with other teams working from different locations, usually the videos won't
work, you have to waste time to fix the problem, if it isn't fixed in a certain amount of
time you need to make alternate arrangements, etc. (One way to tackle the delays in
such calls is for the Scrum Masters from both teams go on the call two minutes
beforehand and ensure that everything is working properly. Also, always keep a
conference bridge number as backup, and after a fixed amount of time — say, five
minutes — spent trying to fix any problems, move to the conference bridge.)

5. Always try to do value stream mapping and see what value-added time is and what is
not. This will give you an idea of what your current process efficiency is. Based on
the current state of the value stream map, and by applying Lean practices, you can
improve the cycle time and thereby reduce delays. Also, automate the test cases
wherever possible so that you can reduce a considerable amount of time when you
have to run them recursively.
6. Make sure you get clarity on your assumptions and inputs for your clarifications at
the right time. Raise the red flag before you get into the danger zone, and get proper
attention from respective stakeholders. Track your impediments effectively; the
Scrum Master is responsible for resolving the team's impediments.
57
There are few more possible reasons which can cause the delay in the sprint
development and testing as well:

1. Team over commits — how do you roll user stories (and other product backlog
items) into the next sprint?

2. Team under commits — should you add new user stories mid-sprint?

3. External impediments — how should these be reflected in the burn down chart
and velocity?

4. Product Owner changes — should you allow them to remove, add or significantly
modify the sprint's user stories?

58
6.6 Impact of Delay on testing activities:

There are various factors which impact the Software testing activities few of them are
listed in Common Testing Problems paper by Donald Firesmith

Common Testing Problems Donald Firesmith, 12 September 2012 © 2012 Carnegie

Mellon University.

59
6.7 Impact of Delay on Regression testing:

Common Testing Problems Donald Firesmith, 12 September 2012 © 2012 Carnegie

Mellon University

60
7 Recommendation and Suggestion.

As a part of the research project 10 projects were interviewed. The Interview was based on
questionnaire which was prepared to analyze the impact of the Code Development Delay on
the Testing schedule and the impact on Regression testing activity.

The questionnaire is attached in Appendix section along with the answers to the same.

From the survey following conclusions can be made. The conclusions are divided in parts for
research point of view.

7.1 Agile Projects observations:

1. Approximate length of iteration is 2 to 3 weeks. 60% Projects are having 2 weeks of
Iteration.

2. Regression test gets approximately 2 — 3 days for test execution in a sprint.

7.2 Regression test approach:
1. Regression tests are partially automated in most of the agile projects.

2. Most of the projects (50%) update the regression pack during execution
7.3 Common Problems observed in schedule slippage:

1. It is observed that the Change Requests are received frequently within the sprint.
Causing slippage in development phase in almost all the projects.

2. In most of the above cases the number of days assigned for test execution cycle is
affected. It also affects the regression test execution time.

3. In some cases the delay in Development was observed due to Developers Knowledge
and Understanding of the Requirements and Technology. It also adds up the number
of defects identified in system test and time required for fixing the same.

4. It is also observed that sometimes the implementation of the Requirement becomes so

complex which wasn't calculated before which required spending more time than
planned for development.

5. The Scope of the Sprint is underestimated which causes the schedule disrupting in
Development and Testing.

61
7.4 Impact of the delay on the Regression testing:
1. The last minute modification of regression test suite reduces the available time for
test execution. This can cause the quality of test execution because of lack of time and
dual mindset.
2. At the same time as the tester has to complete the task in insufficient time they tend to
give less importance towards the completeness and correctness of the test cases. This
can also cause certain areas of the test cases to be missing out from getting updated.

3. Duplication of efforts in test design: As we have already discussed earlier that the
same business functions are often changed and enhanced multiple times over many
sprints. As we don't have any mechanism in place which can identify the test cases
getting affected by functional enhancements; this causes the test duplication. When
tester starts writing system test cases based on new requirements he tends to overlook
the similar test cases available in regression test suite which is pointing to the
enhanced functionality. Which can be used as system test just by doing little changes
in the test case; thereby reducing the turn-around time.

4. Duplication of efforts in test execution: Above mentioned point maximize the

chances of duplication of the test cases in System and Regression test suite. These
duplicate test cases in System test and Regression test pack gets executed twice. At
the same time the regression test case is updated based on the change/ enhancement in
the functionality.

5. Execution of obsolete test cases: The change/ enhancement in the functionality can
cause some of the regression test cases to be Obsolete test case, As there is no such
process to identify the obsolete test cases these test cases becomes part of the
regression test suite. This is identified when the test case is half executed causing the
effectiveness of the tester.

6. Key functionality missing from regression pack: The regression pack for iteration is
identified by selecting certain number of test cases from Regression test suite. If the
selection is based on random selection then there can a possibility of missing key
functionality from regression pack. If the test cases are selected on risk based
approach can take longer time to identify the regression pack.

7. Loss of time and efforts if any variance found: As per the current approach of
updating regression test case during execution can affect the mindset of the tester
62
 which led them to go back to base line for cross checking of any variance found in the
expected and Actual results. Further it can cause raising invalid defect as the test case
is not updated as per the functionality enhancement.

8. Chance of defect slippage: Adding to the above point, if the Regression Pack is not
updated; there is always a chance of defect slippage.

9. Bring down the confidence level of tester: All these factors can bring down the
confidence level of the tester in the regression testing

7.5 Problem Mitigation and recommendations:

1. Proper Sprint Planning with optimum number of User Stories which can be developed
and tested in 2 weeks.

2. If the Change Requests need to be added to the current Sprint then project need to
revisit the plan to either adds extra days for testing and regression testing and not just
development or reduce the scope of the Sprint by removing other user stories to next
sprint.

3. Educate the Developers with sufficient Technology and Business knowledge.

4. If it is observed that the implementation came out to be more complex and observed
additional impacted area by the implementation then the same approach as to either
add more days or move some items to next sprint.

5. Add / update regression tests periodically.

6. Automate max number of tests which facilitate the Regression testing over Night
when there is time crunch for execution and can be ran multiple times when ever
required. However the Automation Test should be maintained regularly.

63
8 Results, Conclusion and discussion.

Based on the data analysis we have observed that there is always an impact of the Code
Development delay on the Software testing activities and thus on the quality of the code due
to insufficient testing. Based on the study it is observed that 90% of the sample population is
impacted by development delay due to some or other issues. And in 40% of cases the time
delay is more than 20% of development efforts.

Testing Cycle Sprint X

Plan
Coding
System Testing
Regression
Testing
Actual
Coding
System Testing
Regression
Testing

8 hours
8 hours

Figure 7 Impact of Code Development delay in the testing timelines.

There are various reasons of delay observed but the most common are the once which are
captured in the questionnaire. There are internal and external factors impacting the
development schedule. We have considered only internal factors for the research
questionnaire. 50% of the development delay is observed due to the due to the initial
understanding of the User Story and Assumptions/clarifications and impediments of the same
or over commitment from the team. It is observed that 40% of development delay is due to
improper sprint planning may be due to lack of knowledge of the functionality under scope or
functionality not properly analyzed before planning which increased the development efforts
within the sprint. 90% of the projects observed the Change Requests and they have accepted
the change within the same sprint. This change usually impacts the scope of the development
and testing impacting the sprint estimate.

64
As discusses the delay in the Development has reduced the estimated test execution time.
70% of the projects were impacted by the development delay reducing available time for
testing. However at the same time for most of the projects the sprint dead line is not increases
which will be discussed in the further questions.

Based on the below table the projects is said to be impacted by the Delay. If the Testing time
reduction is Less than 20 % then the Testing time is considered as not impacted however if it
is greater than or equal to 20% then the project is said to be impacted with reduction in
testing time.

Functional testing time reduction observed?

Response < 20% 20 to 30% > 30%
Projects 3 5 2

Which means out of 10 project 30% projects is Not Impacted and 70% of projects are
impacted.

It is observed that not all the projects get schedule extension for the increased in the scope of
the testing due to the change request which means the development and testing has to be fit
into the given time resulting in delay in both development and testing activity. For which
both the teams need to stretch and try and complete related activities in given time. Only
20% of the projects get the required extension however the same is not sufficient to
accommodate the change.

For regression test completeness it is important the regression tests are maintained over the
sprints. It is observed that only 40% of the projects do this activity and 60% does not
primarily due to the unavailability of time for this activity.

60% of the projects update the regression tests during the execution. At the same time as the
tester has to complete the task in insufficient time they tend to give less importance towards
the completeness and correctness of the test cases. This can also cause certain areas of the
test cases to be missing out from getting updated.

When tester starts writing system test cases based on new requirements he tends to overlook
the similar test cases available in regression test suite which is pointing to the enhanced
functionality. These test cases can be used as system test just by doing little changes in the

65
test case; thereby reducing the turn-around time. Above mentioned point maximize the
chances of duplication of the test cases in System and Regression test suite. These duplicate
test cases in System test and Regression test pack gets executed twice. At the same time the
regression test case is updated based on the change/ enhancement in the functionality.

It is observed that 80% of the projects reduce the regression test count to fit the testing in
given timescale. When reduction of the regression count is the only option 40% of teams use
risk based approach where the tests are prioritized and High Priority tests are executed.
However it is observed that 40% of the projects use random selection approach which may
result in missing important tests for the regression test suite. If the selection is based on
random selection then there can a possibility of missing key functionality from regression
pack. If the test cases are selected on risk based approach can take longer time to identify the
regression pack. All these factors can bring down the confidence level of the tester in the

66
9 References
Agile Methodology. (n.d.). Retrieved 08 15, 2014, from Agile Methodology:
http://agilemethodology.org/
Agile software development. (2014, 08 10). Retrieved 08 15, 2014, from Wikipedia, the free
encyclopedia: http://en.wikipedia.org/wiki/Agile_software_development
Beedle, M. (2001, 02 13). Manifesto for Agile Software Development. Retrieved 08 15, 2014,
from Manifesto for Agile Software Development: http://agilemanifesto.org/
Cole, M. (2013, 12 12). Major Challenges in Agile Testing & The Role of Automation.
Retrieved 08 15, 2014, from articlesbase: hap://www.articlesbase.conl/
J.B.Rajkumar. (2012, 11 30). Automated Regression Testing Challenges in Agile
Environment. Retrieved 08 15, 2014, from Software Testing Help:
http://www.softwaretestinghelp.conVautomated-regression-testing-challenges-in-agile-
testing-environment/
Leffingwell, D. (2007). Whitepaper-Mastering the Iteration. In Scaling Software Agility: Best
Practices for Large Enterprises. Addison-Wesley.
Sami, M. (2012, 03 15). Software Development Life Cycle Models and Methodologies.
Retrieved 08 15, 2014, from Software Engineering Practices:
http://melsatar.wordpress.com/2012/03/15/software-devel opment-life-cycle-models-and-
methodologies/
Sikka, V. (2014, 11 5). Infosys CEO. (B. K. John, Interviewer)
Vennapoosa, C. (2006, 06 04). Testing for Agile Software Development. Retrieved 08 15,
2014, from Exforsys Inc: http://www.exforsys.conl/
Advanced Development Methods, Inc. (2009). Scrum, Retrieved February 2, 2009, from
http://www.controlchaos.com.
Agar, M. H. (1980). The professional stranger: An informal introduction to ethnography.
New York: Academic Press.
Agile Logic. (2006). Agile logic. Retrieved March 20, 2009, from
http://www.agilelogic.com.
Ambler, S. (2005). A manager's introduction to the Rational Unified Process (RUP).
Retrieved Feb 20, 2009, from
http://www.ambysoft.conVdownloads/managersIntroToRUP.pdf
Anacon, D. (1990). Outward bound: Strategies for team survival in an organization.
Academy of Management Journal, 33(2), 334-365.
67
Avison, D., Lau, F., Myers, M., & Nielsen, P. A. (1999). Action research. Communications
of the ACM, 42(1), 94-97.
Awad, M. A. (2005). A comparison between agile and traditional software development
methodologies. Unpublished doctoral dissertation, The University of Western Australia,
Australia.
Balijepally, V. (2005). Collaborative software development in agile methodologies —
Perspectives from small group research. Proceedings of the Eleventh Americas
Baskerville, R.L., & Wood-Harper, A.T. (1996). A critical perspective on action research as a
method for information systems research. Journal of Information Technology, 11, 235-246.
Batra, D., Sin, T., & Tseng, S. (2006). Modified agile practices for outsourced softwa re
projects. Proceedings of the Twelfth Americas Conference on Information Systems,
Acapulco, Mexico, August 4-6, 2006, 3872-3880.
Beck, K. (2000). Extreme programming explained: Embrace change. Reading, MA:
Addison-Wesley.
Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., et al.
(2001). Manifesto for agile software development. Retrieved December 10, 2008, from
http://www.agilemanifesto.org/
Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., et al.
(2001). Principles behind the agile manifesto. Retrieved January 19, 2009, from
http://www.agilemanifesto.org/principles.html
Benbasat, I., & McFarlan, W. (Eds.). (1984). An analysis of research methodologies in the
information systems research challenge. Boston: Harvard Business School Press.
Cao, L., Mohan, K., Xu, P., & Ramesh, B. (2004). How extreme does extreme programming
have to be? Adapting XP practices to large-scale projects. Proceedings of the 37th Hawaii
International Conference on System Sciences, 1- 10.
Charmaz, K. (2002). Qualitative interviewing and grounded theory analysis. In J. F. Gubrium
& J.A. Holstein, Handbook of qualitative research (2nd ed, pp. 675- 694). Thousand Oaks,
CA: Sage.
Cockburn, A. (2007). Agile software development: The cooperative game. Upper Saddle
River, NJ: Addison-Wesley.
Cottrell, N. B. (1972). Social facilitation, in C.G. McClintock (Ed.). Experimental Social
Psychology, Holt, New York, 185-236.

68
Forrester Research, Inc. (2005). Corporate IT leads the second wave of agile adoption.
Cambridge, MA. Fowler, M. (2005). The new methodology. Retrieved December 10, 2008,
from http://martinfowler.com/articles/newMethodology.html
Boston: Allyn and Bacon. Glaser, B. G. (1978). Theoretical sensitivity: Advances in the
methodology of grounded theory. Mill Valley; CA: Sociology Press. Glaser, B. G., & Strauss,
A. L. (1967). The discovery of grounded theory: Strategies for qualitative research. New
York: Aldine. Glesne, C. (2006). Becoming qualitative researchers. Boston: Pearson.
Hickey, A. M., & Davis, A. M. (2004). A unified model of requirements elicitation.
Journal of Management Information Systems, 20(4), 65-84.
Highsmith, J., & Cockburn, A. (2001, September). Agile software development: The
business innovation. IEEE Computer, 34(9), 120-122.
Hodgetts, P. (2009). Product development with Scrum. Retrieved February 1, 2009, from
http://www.agilelogic.com.
Isabella, L. A. (1990). Evolving interpretations as a change unfolds: How managers construe
key organizational events. Academy of Management Journal, 33(1), 7- 41.
Jones, C. (1997). Applied Software Measurements. Highstown, NJ: McGraw-Hill.
Kahn, W. A. (1990). Psychological conditions of personal engagement and disengagement at
work. Academy of Management Journal, 33(4), 248-266.
Kaplan, B., & Maxwell, J. A. (1984). Qualitative research methods for evaluating computer
information systems. Thousand Oaks, CA: Sage.
Kaplan, R. S. (1985). The role of empirical research in management accounting. Boston:
Harvard Business School.
Kruchten, P. (2004). The rational unified process: An introduction Ord ed). Reading,
MA: Addison-Wesley Longman.
Larman, C. (2007). Agile and iterative development. Boston: Addison-Wesley.
Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. Upper
Saddle River, NJ: Addison-Wesley.
Levi-Strauss, C. (1966). The savage mind (2nd ed.). Chicago: University of Chicago Press.
Jones, C. (1997). Applied Software Measurements. Highstown, NJ: McGraw-Hill.
Kahn, W. A. (1990). Psychological conditions of personal engagement and disengagement at
work. Academy of Management Journal, 33(4), 248-266.
Kaplan, B., & Maxwell, J. A. (1984). Qualitative research methods for evaluating computer
information systems. Thousand Oaks, CA: Sage.

69
10 Appendices

Appendix A — Acronyms
Acronyms Description
Agile Agile software development is a group of software development
methods based on iterative and incremental development, where
requirements and solutions evolve through collaboration between

BA self-organizing,
Business Analystcross-functional teams.
CR Change Request
ITR Iteration
Req Requirement
ROI Return on Investment
Scrum Scrum is an iterative and incremental agile software development
method for managing software projects and product or application
Sprint/Iteration development.
Iteration means the act of repeating a process usually with the aim
of approaching a desired goal or target or result.

70
Appendix B — Questionnaire: The Questionnaire was distributed and collected online in MS Excel format over Email:

Sr. No Questions Objective 1 Objective 2 Objective 3

la Name of the Stakeholder Interviewed? Free Text Free Text Free Text
Designation of the Stakeholder Interviewed? (Team Lead,
lb Free Text Free Text Free Text
Manager or Team member?)
lc Years of experience in IT industry? Free Text Free Text Free Text

2 Project and Domain Name? Free Text Free Text Free Text
3 Size of the Test Team? Free Text Free Text Free Text
Does the project using Agile Methodology for software
4 Development? Yes No
5 Number of Sprints completed till Date? Free Text Free Text Free Text
Approximate/Average Length of one Iteration/Sprint? (in
6 1 Week 2 Weeks > 2weeks
weeks)
7 Regression Test cases are Automated? Yes No Partly
8 Do you observe Delays in Development? Yes No Some Times
9 Delay in % Development time 0% <=20% >20%
10 Impact of the delay on the regression testing time? Yes No Some Times
11 Regression testing time reduction observed? <20% 20 to 30% >30%
What are the Probable Reasons for the Code Deployment Dev Team is not Complexity in
12 Competent the Requirement Sprint Planning
Delay?
Do you get the Change Requests frequently within the
13 sprint? Yes No Some Times

71
Sr. No Questions Objective 1 Objective 2 Objective 3
14 Do you get schedule extension for Regression testing? Yes No Some Times
Do you get time to update and maintain the Regression test
15 Pack? Yes No
16 When do you Update the impacted Regression test During Planning During Execution In Free Time
17 Do you observe Duplication of efforts in test design? Yes No
18 Do you observe Duplication of efforts in test execution? Yes No
19 Do you end up in Executing obsolete test cases? Yes No
20 Do you reduce the Regression test count in Crunch Time? Yes No Some times
21 How do you eliminate the Regression tests? Random Risk Based Execute All
Have you observed the Key functionality missing from
22 regression pack due to the test scope reduction? Yes No Some Times
Have you spent time and efforts if any variance found due
23 to absolute or out dated tests? Yes No Some Times
Have you observed Defect slippage due to insufficient
24 Regression testing? Yes No Some Times

72