Agile Testing

• Agile Testing is a software testing practice that follows the

principles of agile software development.
• Agile Testing involves all members of the project team, with
special expertise contributed by testers. Testing is not a
separate phase and is interwoven with all the development
phases such as requirements, design and coding and test case
generation. Testing takes place simultaneously through the
Development Life Cycle.
• Furthermore, with testers participating in the entire
Development Lifecycle in conjunction with cross-functional
team members, the contribution of testers towards building the
software as per the customer requirements, with better design
and code would become possible.
 Agile Testing Principles
The principles of Agile testing are −
• Testing moves the project forward − Continuous testing is the only way
to ensure continuous progress. Agile Testing provides feedback on an
ongoing basis and the final product meets the business demands.
• Testing is not a phase − Agile team tests alongside the development team
to ensure that the features implemented during a given iteration are actually
done. Testing is not kept for a later phase.
• Everyone tests − In agile testing, the entire team including analysts,
developers, and testers test the application. After every iteration, even the
customer performs the User Acceptance Testing.
• Shortening Feedback Loops − In Agile Testing, the business team get to
know the product development for each and every iteration. They are
involved in every iteration. Continuous feedback shortens the feedback
response time and thus the cost involved in fixing it is less.
• Keep the Code Clean − The defects are fixed as they are raised within the
same iteration. This ensures clean code at any milestone of development.
• Lightweight Documentation − Instead of comprehensive test
documentation, Agile testers −
– Use reusable checklists to suggest tests.
– Focus on the essence of the test rather than the incidental details.
– Use lightweight documentation styles/tools.
– Capture test ideas in charters for exploratory testing.
– Leverage documents for multiple purposes.
• Leveraging one test artifact for manual and automated tests − Same
test script artifact can be utilized for manual testing and as an input for
automated tests. This eliminates the requirement of Manual Test
Documentation and then an equivalent Automation Test Script.

• “Done Done,” not just done − In Agile, a feature is said to be done not
after development but after development and testing.

• Test-Last vs. Test Driven − Test Cases are written along with the
requirements. Hence, development can be driven by testing. This approach
is called Test Driven Development (TDD) and Acceptance Test Driven
Development (ATDD). This is in contrast to testing as a last phase in
Waterfall Testing.
Agile Testing Lifecycle
 1. Iteration 0 – Initiation of a project

• In Iteration 0, you complete the tasks in the initial

setup. This task requires selecting individuals for
testing, installation, test software, resource planning,
etc. The following steps are defined for this stage.
• Business case development for the project.
• Define the parameters and scope of the project.
• Define key criteria and use cases to inform trade-offs in
design.
• Describe potential architectures.
• Identification of possible risks.
• Planning of initial project and estimation of costs.
 2. Development Iterations

During development iterations, the agile project managers

Deliver continually high-quality working apps to satisfy our
stakeholder‟s needs.
• It is possible by:
• Working together
• Analyzing and designing
• Ensuring quality.
• Delivering working software daily
• Testing repetitions
 3. Release End Game
• The aim is to deploy your system efficiently in
production. At this level, the operations involve training
users, support persons, and organizational personnel. It
also includes product release marketing, back-up &
recovery, system finalization, and user manuals.
• The final phase of the agile methodology includes
complete system testing and acceptance testing. You
should test the product more rigorously when
constructing iterations to achieve the final testing stage
without any obstacles.
 4. Production
The purpose of the production stage is to ensure
that applications become efficient once
introduced to the users.

This method can vary from one organization to

another organization, maybe from process to
process, but the basic purpose is to keep the
system working and to allow people to operate
the system.
 Quadrants of Agile Testing

Combining the two aspects of Testing Types, the following

Agile Testing Quadrants are derived by Brian Marick −
• The Agile Testing Quadrants provide a helpful taxonomy to
help teams identify, plan and execute the testing needed.
• Quadrant Q1 − Unit Level, Technology Facing, and
supports the developers. Unit tests belong to this Quadrant.
These tests can be Automated tests.
• Quadrant Q2 − System level, business facing, and conform
product behavior. Functional tests belong to this quadrant.
These tests are either manual or automated.
• Quadrant Q3 − System or User Acceptance Level,
Business Facing and focus on real time scenarios. User
Acceptance Tests belong to this quadrant. These tests are
manual.
• Quadrant Q4 − System or Operational Acceptance Level,
Technology Facing and Focus on Performance, Load,
Stress, Maintainability, Scalability Tests. Special tools can
be used for these tests along with automation testing.
 Agile acceptance testing
Agile acceptance testing is a combination of traditional
functional testing and traditional acceptance testing as
the development team, and stakeholders are doing it
together.

While developer testing is a mix of traditional unit

testing and traditional service integration
testing. Developer testing verifies both the application
code and the database schema.
 What is UAT?

User Acceptance Testing (UAT) is a type of testing

performed by the end user or the client to verify/accept
the software system before moving the software
application to the production environment. UAT is done
in the final phase of testing after functional, integration
and system testing is done.
 Purpose of UAT
The main Purpose of UAT is to validate end to end
business flow. It does not focus on cosmetic errors,
spelling mistakes or system testing. User Acceptance
Testing is carried out in a separate testing environment
with production-like data setup. It is kind of black box
testing where two or more end-users will be involved.
 Continuous Integration
Continuous integration is a critical technical
practice for each Agile Release Train (ART).

It improves quality, reduces risk, and establishes a

fast, reliable, and sustainable development pace.
With continuous integration, the “system always
runs,” meaning it‟s potentially deployable, even
during development.
With continuous integration, the “system always runs,”
meaning it‟s potentially deployable, even during
development.

CI is the second aspect in the four-part Continuous

Delivery Pipeline .
a. Continuous Exploration (CE)
b. Continuous Integration (CI)
c. Continuous Deployment
c. Release on Demand
 The Four Activities of Continuous
Integration
Develop describes the practices necessary to implement
stories and commit the code and components to version
control
Build describes the practices needed to create deployable
binaries and merge development branches into the trunk

Test end-to-end describes the practices necessary to

validate the solution

Stage describes the practices necessary to host and validate

the solution in a staging environment before production
 Code Refactoring
Refactoring is the activity of improving the
internal structure or operation of a code or
component without changing its external
behavior.

The goal of software development is the

continuous delivery of business value to users
and stakeholders.
Two paths to the future exist:
1. Keep adding new functionality to an existing
code base toward an eventually unmaintainable
“throw-away” state
2. Continuously modify the system to provide a
foundation for efficiently delivering not just the
current business value but future business value as
well

The second choice, refactoring, is better. With

continuous refactoring, the useful life of an
Enterprise‟s investment in software assets can be
extended as long as possible, and users can continue
to experience a flow of value for years to come.
 Risk based testing
If a QA team struggles with deciding how to allocate time and
effort in each sprint, their best bet is using risk-based testing.

This refers to a testing strategy that uses „defined risk‟ to

determine testing goals.

In other words, the risk-based testing approach organizes testing

efforts in ways that lower the residual level of product risk when
the software goes into production. This strategy is useful for test
analysis, planning, estimation, design, execution, and results
reporting.
 What exactly is a ‘risk’?

Risk refers to the occurrence of an unforeseen event that

can impact the success of a product (software, in this
case).

These events could have occurred in the past or may be

a concern for future occurrences. Risks can serve as a
reliable parameter to plan, schedule, and allocate tester
effort.
Purpose of risk-based testing in Agile

• Risk-based testing applies the principles of risk

management to testing activities. It aims to:
1. Create and offer a framework that facilitates
clear discussion between testers, developers, and
other stakeholders about the risks at hand.
Essentially, it isolates risks to make them
identifiable and actionable.
• Cover customer needs as well as developer
needs when considering what counts as a risk.
• Provides the criteria to decide how to manage
budgets, negotiate timelines, avoid delay – all
without affecting software quality.
• Highlights what features/issues matter most
to customers, thus creating a hierarchy of
testing requirements.
 How to conduct risk based testing in
Agile?
• Before creating a plan for risk-based testing, ask
the following questions:
• What needs to be tested first?
• How to reduce the testing effort?
• How many features can be covered with each test
cycle?
• How to decide what not to test?
• What metrics are required to measure testing
success here?
 Regressing testing
Regression testing in agile helps development teams
concentrate on new functionality, while maintaining
stability with every new product increment.

Teams use regression testing to make sure that tested

software continues to perform after every modification
• In agile, testing needs to develop with each sprint and testers
must make sure that new changes do not affect existing
functionality of the application. This is known as regression
testing.
• Regression testing ensures that previous functionality of the
application works effectively and new changes have not
introduced new bugs.

• Regression tests should be employed whether there is a small

localized change to the software or a larger change. Teams
must verify that new code does not conflict with older code,
and that code that has not been changed is still working as
expected.
In agile, there are frequent build cycles and continuous changes
are added to the application. T

his makes regression testing in agile essential.

For successful regression testing in agile, a testing team should

build the regression suite from the onset of product development.
They should continue building on it alongside development
sprints

.
Regression Testing Methods
There are three ways to undertake regression testing. The
approach you select will vary according to your circumstances,
the size of your codebase, the number of testers on your team,
and your available resources.

• Re-test everything—involves rerunning all existing tests on the

new codebase. If the tests were well designed, this will isolate
regressions. However, this method is resource intensive and
may not be feasible for a large codebase.
• Selective re-testing—it is sometimes possible to identify a
subset of your existing tests that can address all or almost all
of the “moving parts” of your codebase. It is then sufficient to
re-run that selective set to discover regressions across the
codebase.
• Prioritized re-testing—used on large codebases. The priority
tests address code paths, user actions and areas of functionality
expected to contain bugs. Once these tests have run you can
complete the remaining tests
 Test Automation
Agile Automation Testing in software development is an
approach of using test automation in agile methodologies.

The purpose of agile automation testing is to make the software

development process more effective and efficient while
maintaining the quality and time as well as resource
consumption.

Thus, the implementation of such a process requires a lot of

coordination and collaboration between teams.
Automation Testing is normally feasible when the application
is stable, steady and the requirement is involving with a real
considerable amount of time and in most cases involving a set of
very skillful automation expert resources as well as a
considerable amount of set-up costs.

The basic purpose of Automation Testing is to reduce costs over a

long time and to ensure no new defects have been introduced as a
result of existing test cases.
Importance of Test Automation in Agile Testing:
1. Effective rise in development output:
The short development cycle is the most important factor that demands automation in agile
testing. The Agile teams have short time frames to grasp the requirement, build the code and
then regress those changes..
2. Efficiently resolving recurring changes:
We are all well acquainted with the fact that projects rarely come with a pre-decided set of
requirements. The requirements are developed and changed over time depending upon the
priorities of the business.
3. Easily identifying the code issues:
Test Automation allows the tester to test the code quickly without hampering the quality of
testing. It also comes with a collection of pre-decided test scripts that help to identify the
issues effectively.
4. Thorough and continuous testing:
Automation allows repeated and exhaustive examination of the code with a detailed
overview. A thorough and continuous testing helps in ensuring the quality of the code.
5. Automated test support activities:
Test Automation not only contributes in carrying out test scripts but also supports in
automating other test activities like test reporting, result validation and data set up. Agile
testing requires repeated code of arrangements which can be programmed by test
automation. It subsequently releases the testers from the mundane and laborious tasks.
 Verify stories
When a user story has been developed and tested, the product
owner then reviews the functionality and verifies that it meets the
goals of the user story.

The product owner verifies user stories throughout each day.

Finally, the product owner should run through some checks to

verify that the user story in question meets the definition of done.

When a user story meets the definition of done, the product

owner updates the task board by moving the user story from the
Accept column to the Done column.