Skip to content

Techniques used in Agile Testing

Testing techniques used in traditional testing can also be used in Agile testing. Furthermore, Agile projects make use of specific testing techniques and terminologies that are tailored to the Agile methodology.

In Agile projects, the product backlog replaces the requirements specification documents and the test basis is the user story. To ensure effective quality testing, additional sources can be considered such as: 1. Experience from previous iterations of the same project or past projects. 2. Existing functions, architecture, design, code, and quality characteristics of the system. 3. Defect data from the current and past projects. 4. Customer feedback. 5. User documentation.

Definition of Done

The Definition of Done (DoD) is a criteria used in Agile projects to ensure completion of an activity in the Sprint backlog. It serves as a checklist of necessary activities that need to be accomplished so that a user story reaches the Done stage. DoD should be consistent within one team, and it should include the following items: 1. Detailed Testable Acceptance Criteria 2. Criteria to ensure consistency of the User Story with the others in the Iteration 3. Specific Criteria related to the Product 4. Functional Behavior Aspects 5. Non-functional characteristics 6. Interfaces 7. Test Data Requirements 8. Test Coverage 9. Refactoring 10. Review and Approval Requirements DoD is also needed for every level of testing, for each feature, for each Iteration, and for Release. It is essential to have a clear and consistent DoD that is shared across the team to ensure the successful completion of a user story.

Test Information


A tester needs to have the following Test information in order to be able to effectively perform their job: 1. User Stories that need to be tested: This is the basis for testing and should be clearly understood in order to plan and execute appropriate tests. 2. Associated Acceptance Criteria: This provides a clear set of criteria that must be met in order for the User Stories to be considered successful. 3. System Interfaces: This is important in order to understand the interactions between components of the system. 4. Environment where the System is expected to Work: This is important in order to understand the conditions under which the system must work and how it should behave in different environments. 5. Tools availability: This is important to ensure that the right tools are available to carry out the tests. 6. Test Coverage: This is important to ensure that all the requirements are covered by the tests. 7. DoD: This is important to ensure that the tests meet the level of quality that is expected. 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: 1. Obtain necessary test information on an ongoing basis: This is important to ensure that the tests are up-to-date and relevant. 2. Identify the information gaps that affect testing: This is important to ensure that all the necessary information is available and any gaps are identified and addressed. 3. Resolve the gaps collaboratively with other team members: This is important to ensure that the gaps are addressed in a timely manner and that all team members are involved in the process. 4. Decide when a test level is reached: This is important to ensure that the tests are sufficient and complete. 5. Ensure appropriate tests executed at relevant times: This is important to ensure that the tests are executed in the right environment and at the right time.

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 can be applied to design the relevant test cases. These techniques allow testers and developers to identify the various scenarios and test conditions that should be met in order for the system to be successful. They can then devise test cases to verify that these conditions are met. This helps ensure that the system is robust and meets all the requirements.

Exploratory Testing

Exploratory Testing (ET) is a testing approach that combines learning, test design, and test execution within a single process. It is often used in Agile projects due to the limited time available for Test Analysis and Test Design. The tester actively controls the design of the tests as they are being performed and uses the information gained while testing to create more effective tests. This technique is useful for quickly adapting to changes in Agile projects.

Risk-Based Testing


Risk-Based Testing is a method of testing that is based on the risk of failure and focuses on mitigating those risks. It involves the following steps: 1. Identifying potential product quality risks: This includes functional, non-functional performance, and non-functional usability risks. 2. Evaluating the probability (likelihood) and impact of each risk: Risk analysis is done to determine the severity of the risks. 3. Prioritizing the risks: High risks require extensive testing, while lower risks require only cursory testing. 4. Designing tests using appropriate test techniques: This is based on the risk level and risk characteristics of each risk. 5. Executing the tests: Tests are then executed to mitigate the risks.

Fit Tests

Fit Tests are automated Acceptance Tests which can be used to test software applications. They use the tools Fit and FitNesse to automate the tests. For Fit Tests, HTML tables are used to display the test cases, and the Fixture class is used to run the test cases on the project being tested. The Fixture class is a Java class which takes the contents of the HTML table and uses JUnit to run the tests.

Leave a Reply

Your email address will not be published. Required fields are marked *