- Agile Testing Tutorial
- Agile Testing - Home
- Agile Testing - Overview
- Agile Testing - Methodologies
- Agile Testing - Tester in Team
- Agile Testing - Tracking Activities
- Agile Testing - Significant Attributes
- Agile Testing - Quadrants
- Agile Testing - Scrum
- Agile Testing - Methods
- Agile Testing - Techniques
- Agile Testing - Workproducts
- Agile Testing - Kanban
- Agile Testing - Tools
- Agile Testing Useful Resources
- Agile Testing - Quick Guide
- Agile Testing - Useful Resources
- Agile Testing - Discussion
Agile Testing - Techniques
Testing Techniques from traditional testing can also be used in Agile testing. In addition to these, Agile specific testing techniques and terminologies are used in the Agile projects.
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.