Agile Testing - Techniques

Test Basis

In agile projects, the product backlog replaces the requirements specification documents. The contents of product backlog are normally user stories. The non-functional requirements also are taken care in the user stories. Thus, the test basis in Agile projects is the user story.

To ensure quality testing, the following can also be considered additionally as test basis −

Experience from previous iterations of the same project or past projects.
Existing functions, architecture, design, code, and quality characteristics of the system.
Defect data from the current and past projects.
Customer feedback.
User documentation.

Definition of Done

The Definition of Done (DoD) is the criteria that is used in Agile projects to ensure completion of an activity in the Sprint backlog. DoD can vary from one Scrum team to another, but it should be consistent within one team.

DoD is a checklist of necessary activities that ensure implementation of functions and features in a user story along with the non-functional requirements that are part of the user story. A user story reaches the Done stage after all the items in the DoD checklist are accomplished. A DoD is shared across team.

A typical DoD for a user story can contain −

Detailed Testable Acceptance Criteria
Criteria to ensure consistency of the User Story with the others in the Iteration
Specific Criteria related to the Product
Functional Behavior Aspects
Non-functional characteristics
Interfaces
Test Data Requirements
Test Coverage
Refactoring
Review and Approval Requirements

In addition to the DoD for User Stories, DoD is also required −

at every Level of Testing
for each Feature
for each Iteration
for Release

Test Information

A tester needs to have the following Test information −

User Stories that need to be tested
Associated Acceptance Criteria
System Interfaces
Environment where the System is expected to Work
Tools availability
Test Coverage
DoD

In Agile projects, as testing is not a sequential activity and testers are supposed to work in a collaborative mode, it is the tester’s responsibility to −

Obtain necessary test information on an ongoing basis.
Identify the information gaps that affect testing.
Resolve the gaps collaboratively with other team members.
Decide when a test level is reached.
Ensure appropriate tests executed at relevant times.

Functional and Non-Functional Test Design

In Agile projects, the traditional testing techniques can be used, but the focus is on early testing. Test cases need to be in place before the implementation starts.

For Functional test design, the testers and developers can use the traditional Black Box test design techniques such as −

Equivalence Partitioning
Boundary Value Analysis
Decision Tables
State Transition
Class Tree

For non-functional test design, as the non-functional requirements are also a part of each user story, the black box test design techniques only can be used to design the relevant test cases.

Exploratory Testing

In Agile projects, time is often the limitation factor for Test Analysis and Test Design. In such cases, Exploratory testing techniques can be combined with the traditional testing techniques.

Exploratory Testing (ET) is defined as simultaneous learning, test design and test execution. In Exploratory Testing, the tester actively controls the design of the tests as they are performed and uses the information gained while testing to design new and better tests.

Exploratory Testing comes handy to accommodate changes in Agile projects.

Risk-Based Testing

Risk-based testing is testing based on the risk of failure and mitigates the risks using test design techniques.

A Product quality risk can be defined as a potential problem with product quality. Product quality risks include −

Functional risks
Non-functional performance risks
Non-functional usability risks

Risk analysis is to be done to evaluate the probability (likelihood) and impact of each risk. Then, the risks are prioritized −

High Risks require Extensive Testing
Low Risks require only Cursory Testing

Tests are designed using appropriate Test Techniques based on the Risk Level and Risk Characteristic of each Risk. Tests are then executed to mitigate the Risks.

Fit Tests

Fit Tests are automated Acceptance Tests. The Tools Fit and FitNesse can be used for automating acceptance tests.

FIT uses JUnit, but extends the testing functionality. HTML tables are used to display the Test cases. Fixture is a Java class behind the HTML table. The fixture takes the contents of the HTML table and runs the test cases on the project being tested.

Previous Page Print Page