Implementation of agile

methodology in system
testing

N V Saraswathi Sneha
Software Engineering Analyst
Accenture Services Pvt Ltd
Bangalore
01/01/2025 1
 abstract

This white paper covers the feasibility of fitting

Agile Methodology into current work practices
with respect to System Testing for agile
delivery of tests without deterioration in the
quality. I have also emphasized the iterative
approach for achieving maximum efficiency in
the implementation of Agile Practices in
System Testing for promoting faster and
efficient results in comparison to the
traditional approach.
01/01/2025 2
 Test
Requiremen
Requiremen Test Design
t Analysis
ts

Test Data
system test approach Preparation

Defect Defect Test

Tracking Logging Execution

Defect
Retesting Status
Update

01/01/2025 3
Traditional Approach for a system test
• Certain number of requirements are planned under a specific
drop/release within a dedicated timeline.
• Feasibility docs for various ID’s of a specific drop/ release are
at once uploaded in the share path specific to a project.
• As the FD’s are uploaded, they are distributed equally to the
testing team for Design.
• The Design phase of a specific ID covers both Analysis and
Design by an individual tester.
• Parallel to this, the developers Analyse, create TD, build the
code, perform unit test and install the package in the testing
environment.
• Once installed, the tester who designed a specific ID picks up
the same ID for test data preparation and execution.
• If any defects found, the tester raises a defect.
• Once fixed, the tester re-tests and updates the defect status.
01/01/2025 4
 ID allocation

ID1 ID2 ID3

DESIG DESIG DESIG
N N N

TESTER TESTER TESTER C

A B

DATA DATA DATA

PREPARATIO PREPARATIO PREPARATIO
N N N

EXECUTIO EXECUTIO
EXECUTIO N
N N

DEFECT DEFECT DEFECT

LOGGING LOGGING LOGGING
01/01/2025 5
 DRAWBACKS OF THIS APPROACH
• Clarity in design documentation is directly
proportional to depth of understanding put
forward by an individual tester.
• Understanding of any requirement is directly
proportional to the experience of a tester.
• Design documentation prepared by a
experienced tester might be much
understandable in comparison to that
performed by a tester who is fresher.
• When Tester A picks up the design , he picks
up the data preparation followed by
execution, defect logging and closure of the
ID.
• Tester A completes the SDLC cycle for one
particular ID.
01/01/2025 6
Contd….
• ID’s when assigned in a random manner to
random testers cannot preview a stipulated
deadline.
LESS
COMPLEX COMPLEX
ID ID

LESS VARIE EXPERIENCED

EXPERIENCED D TESTER
TESTER TIME

01/01/2025 7
 Contd….
Defects handled by the Tester A is practically re-tested by the same
tester.
In case if Tester A is not available, the other testers need to
understand the complete requirement and the background of the
system test scenario in-order to handle the re-testing of the defect.
If an ad-hoc requirement based on a system test scenario of an ID
is placed, it becomes a trend that the tester responsible for the ID
has to pick it up else prolonged time/deterioration in quality tends
to be the end result which brings dissatisfaction to the
client/customers.
What could be a better methodology that assures a delivery which
is;
 Prompt
 Reliable
 Time-saving
 Low-risk
 High Quality
Here it is; Agile ! a futuristic approach for system test.
01/01/2025 8
 GLIMPSE of AGILE METHODOLOGY
Agile Vs
Traditional
 Individuals &  Processes & Tools
Interactions  Comprehensive
 Working Software Documentation
 Customer Collaboration  Contract Negotiation
 Responding to change  Following a plan
Below Agile Manifesto was derived in 2001 typically based on 4 principles:-

 “Individuals & Interactions over Processes & Tools

 Working Software over Comprehensive documentation
 Customer Collaboration over Contract Negotiation
 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”
01/01/2025 9
-Source - http://en.wikipedia.org/wiki/Agile_software_development#The_Agile_Manifesto
 Futuristic scope for agile approach in
system test

Key STEps involved

Product Backlog
Prioritizing Requirements
Estimation of Requirements using
Planning Poker
Sprint Planning
Daily Status
Continuous Iterations
Burn-down chart
Sprint Retrospective
01/01/2025 10
PRODUCT BACKLOG
Product Backlog is a defined set of prioritized requirements for
constructing a fully functional product.
Product Backlog is written in the form of simple user stories
which might represent any of the following entities in order to
deliver a potentially shippable software.
 Features
 Bug-Fixes
 Production-Fixes
 Enhancements
 Non-functional requirements
The product backlog is held responsible by the product owner
who is aware of the requirements in demand from the business.
Sprint planning will progress based on the user stories picked
up from the product backlog.
Well, in our case all the ID’s could be broken down as user
stories and thereby the product backlog could be built by the
product owner.
Next step will be the prioritizing of the requirements.
01/01/2025 11
Prioritizing requirements
The user stories in a product backlog are prioritized by a
product-owner depending on the following factors;
 Business Risk
 Business Value
 Business Demand
 Business Cost
 Business Timeline
The product-owner possesses full rights to modify the
priority after the estimation of the user stories.
Priority typically decides which requirement has to go first
depending on all the above stated factors.
Product Backlog will evolve over time as the requirements
keep coming and so does the priority changes considering
the updated flow of user stories in the product backlog.

01/01/2025 12
Agile approach

User
Story 1
PRODUCT User
Story 2
Sprint
BACKLOG
Backlog
User
Story 3

2 Week
Sprint
Potentiall
y Continuo
shippable us
product Iteration

01/01/2025 13
Estimation using planning poker
Necessity to Estimate
 To understand the complexity of a given requirement.
 To prioritize the requirements based on complexity in-order to deliver
them within a stipulated deadline.
 To identify the complexity and distribute them equally among the
testers.
Who does the estimation?
 In most other methodologies, the estimation is done only by the
business, client or the manager.
 However, in Agile the estimation is done with the team members.
 When team members estimate any requirement based on their
capacity, they will be able to meet the assured deadline without
breaching the SLA as the estimation is directly acquired from them.
 There must always be a Scrum Master during this estimation who
acts as a mediator between the team members and the product-
owner.
 Scrum Master will not estimate but will be a host for the show.
01/01/2025 14
Contd….
 Planning Poker – widely used technique for Agile
Estimation.
 Estimating Steps
 The Scrum Master, Product-Owner and the team members sit for

estimation together.
 Each team member possesses a set of cards for estimating the

complexity of user stories.

1/
 The cards0 follow 1
Fibonacci 2
Sequence and are numbered in the
2
following manner;

1
3 5 8
3

2 4 10
0 0 0 ?

01/01/2025 15
Planning Poker cards
How to estimate using planning poker?
 A specific user story is picked up from the product
backlog for estimation.
 The requirement is discussed by the product-owner and
the team members share their knowledge with respect to
the requirement.
 Now the team members are completely aware of the
complexity of the requirement.
 Opportunities are given for the team members to clarify
their doubts with respect to the user story.
 Once every aspect of the user story is clarified, the team
members are now asked to begin the estimation.
 From the set of cards which each team member
possesses, each pick up a number to decide the
complexity of the user story.
01/01/2025 16
Contd….

 Once the card is picked they will place it upside

down on the table so that no one is able to see
the flip side of it.
 Once everybody would pick up, they place their
card on the table with the number hidden.
 The Scrum Master then confirms with everyone if
estimation is done and he requests all of them to
open the cards.
 Each team member would have picked up a
specific number, not all will be the same.
 So each of them support with reasons for choosing
the specific complexity and the discussion
continues until they all agree to a particular
01/01/2025 17
Contd….
 Once the estimation is complete, the story points
are mapped against each user story.
 The product-owner will update the user story
points in the product backlog as well.
 Based on the user story points, the product-owner
possesses the right to modify the priority
depending on the risk factors, so that it could be
accommodated in an upcoming dedicated sprint.
 In Estimations, product-owner
Require 5RC, 5NRC and 1 and Scrum master
5Discounts pack to be tested 2
do not estimate and is done only by the team
3
members (TestersUser stories
or Developers)
Complexity Priority
Need to test 1 RC and 1
discount for a new 2 1
component
01/01/2025 18
SPRINT PLANNING
 In Sprint planning, we typically decide which user story will go
first for the upcoming release.
 The product-owner, scrum master and the entire team will be
present in the sprint planning meeting.
 Together based on the priorities given by the product-owner
from the product backlog, a specific set of user stories will be
picked up for the next release.
 Team members will agree based on the complexity and the
timeline will also be decided.
 A typical sprint will last from 2-4 weeks.
 In case if the sprint is decided to last for 2 weeks, user stories
based on complexity will be picked up from the backlog such
that the team members are able to adhere to the 2 week
deadline as well they are able to deliver the potentially
shippable software.
01/01/2025 19
Daily status
 In Agile Methodology, we have daily status/stand-up
meetings with respect to the
 Tasks
 Tasks Assigned
 Tasks In Progress
 Tasks Done
 Everyday the status has to reflect on the status board that
will be set up next to the team’s workstation.
 In this manner, the entire team will be able to preview the
progress of the tasks.
 In case of any obstacles with respect to the system break-
down, client application errors or any kind of issues faced
during the release, there will be a separate column for
impediments which can be filled on the board and the Scrum
Master will take charge of clearing the impediments on time.

01/01/2025 20
 Contd….
 A typical daily status board looks like this;
DAILY STATUS BOARD

01/01/2025 21
Continuous ITERATIONS with respect to system test

Final
produc
t

01/01/2025 22
Burn Down CHART
 In Agile as we deliver user stories, we also manually make a
burn down chart which demonstrates the user stories
delivered in a given amount of time.
 The total effort against the amount of work delivered in
each iteration is depicted in the burn-down chart and this
demonstrates the rate at which the work is being done in a
given amount of time.
 It also depicts;
 Pending work
 Work completed so far
 Work delivered in each iteration
(Image Source - http://en.wikipedia.org/wiki/Burn_down_chart)

01/01/2025 23
Sprint retrospective
 After the completion of the UAT of the sprint, there is
always a retrospective meeting that is organized.
 In Sprint retrospective, we talk about the various
positive and negative aspects of the sprint like;
 What could have gone wrong?

 What could have been avoided?

 What went right?

 What improvisation has to be adapted for the next

sprint?
 Questions like these are answered to make the next
sprint more productive and enjoyable.
 Anything related to processes, tools, practices,
communications and environments are discussed here.
01/01/2025 24
HOW CAN AGILE be implemented in system test
 ID’s can be split into various small user stories and added to the
product backlog by the business counterpart who will play the
role of a product-owner.
 The product backlog could be shared with the offshore team
and the entire team can sit for estimation meeting along with
the product-owner on-call.
 In the estimation meeting, the testers must be allowed to
estimate the complexity of the requirement and each tester
must be allowed to decide the complexity of a given user story.
 Once the testers come to a conclusion on the same complexity,
the same user story point could be updated in the product
backlog against the specific user story.
 Once the estimations are completed, a sprint planning meeting
can be organized where the user stories from the product
backlog based on the complexity can be allocated for the
upcoming sprint.
 A dedicated timeline can also be previewed for the sprint and
user stories can be added accordingly.
01/01/2025 25
Contd….
 Once the user stories are allotted to the new
sprint, the tasks can be put up on a daily status
board.
 One user story (ID) can be split into tasks like
 Analysis
 Design
 Peer Review Design
 Test data Preparation
 Test Execution
 Defect Logging
 Defect Re-Test
 These tasks can be distributed among different
testers A, B and C
 As Tester A completes the design, Tester B will
peer-review the design documentation.
01/01/2025 26
Contd….
 If the Tester B figures out some errors in the documentation, then and
there it could be clarified from the business and the bugs will never be
taken forward to the next phase.
 As Tester B finishes the peer review, Tester C can prepare the test data
and execute
 If Tester C logs a defect, and if the defect is fixed in his absence, Tester
A or B can take up the re-testing of the defect as all the testers are
completely aware of the requirement.
 When the potential of 3 testers combine together for one user story,
the quality tends to increase and any minor defect doesn’t slip out
during the SDLC phases.
 Since all the user stories will be split equally among the testers based
on the complexity and hence an individual tester will never be
overloaded with all the tasks when compared to the traditional
approach.
 The idea behind Agile is that complex cases are broken down into
simple use cases and testing small piece of requirement absolutely
improves quality, efficiency and is time saving too.
01/01/2025 27
Disadvantages in Traditional Approach of System Test
 In Traditional Approach of System Test, ID’s are allocated
randomly to testers and hence Tester A (fresher) might end up
with a complex requirement and Tester B (experienced) might
end up with a simple requirement.
 The committed deadlines might not be met.
 All testers might not get exposure to different kind of
requirements as an individual tester handles a complete SDLC
cycle for one ID whereas the other tester might not even be
aware of what the requirement is all about.
 Dependency on experienced testers increases if the freshers
doesn’t get an opportunity to work on different kind of
requirements.
 In the absence of Tester A, even if the business comes back for
a particular ID handled by the Tester A, none of the other
testers might be able to respond to their questions as they
would be complete unaware of the requirement which tester A
had been handling.
 This portrays a bad impression to the business and the client. 28
01/01/2025
advantages in Agile Approach of System Test
 In Agile Way of testing the ID’s are not allocated randomly whereas
the sub-tasks of the ID are distributed among different testers and
hence each one will be aware of what the requirement is all about
from analysis to closure of the test.
 The committed deadlines can be easily met as the estimation is
done only by the team members.
 All the testers in the team will get exposure to different kind of
requirements.
 Dependency reduces as the freshers will get a lot of exposure when
they involve in requirements together with the experienced testers.
 Whenever the business/client comes back for a particular ID, any of
the testers from the team will be able to respond to their queries as
each one will be aware of what the requirement is about.
 In this manner, a very harmonious relationship could be maintained
with the client.
 That concludes Traditional Vs Agile Approach in System Testing.

01/01/2025 29
 Sources
http://www.codeproject.com/Articles/604417/Agile-software-d
http://www.mountaingoatsoftware.com/agile/scrum/sprint-retrospe
ctive
/
http://en.wikipedia.org/wiki/Burn_down_chart
http://en.wikipedia.org/wiki/Agile_software_development#The_Agil
e_Manifesto

Thank you
01/01/2025 30