Agile Testing - Techniques

Agile Testing - Modern Techniques

While foundational testing techniques from traditional models remain valuable, Agile testing incorporates these within its iterative and collaborative framework. Furthermore, Agile methodologies have fostered specific techniques and terminologies tailored for rapid, quality-driven development.

Test Basis in Agile

In Agile projects, the primary test basis often originates from user stories within the product backlog, which replace extensive traditional requirements documents. These user stories encapsulate functional requirements, and crucially, non-functional requirements (NFRs) and acceptance criteria are also embedded or linked. Effective Agile teams often use collaborative sessions (e.g., ‘Three Amigos’ - Product Owner, Developer, Tester) to refine user stories and ensure a shared understanding.

To ensure comprehensive and quality testing, the following are also vital components of the test basis:

• Insights and learnings from previous iterations or similar past projects.
• Existing system architecture, design documents, code, and established quality attributes.
• Defect history and patterns from current and past projects.
• Direct customer feedback and user research.
• User documentation, API specifications, and design mockups.
• Personas and user journey maps.

Definition of Done (DoD)

The Definition of Done (DoD) is a critical, shared understanding within an Agile team about the criteria a product increment (e.g., a user story) must meet to be considered complete. While the DoD can evolve, it must be consistently applied by the team. It serves as a quality gate for all work.

The DoD is essentially a checklist ensuring that all necessary activities for a user story—including functional implementation, non-functional aspects, testing, and documentation—are accomplished. A user story is only moved to ‘Done’ when all DoD items are satisfied. This helps prevent technical debt and ensures shippable increments.

A comprehensive DoD for a user story might include:

• Clear, testable acceptance criteria defined and met.
• Code peer-reviewed.
• Unit tests written and passing (achieving agreed-upon code coverage).
• Integration tests written and passing.
• Relevant end-to-end tests updated/created and passing.
• Performance and security considerations addressed.
• User documentation (if applicable) updated.
• Product Owner acceptance.
• Successfully deployed to a staging/testing environment.
• No critical or high-severity defects outstanding.

In addition to the DoD for User Stories, a DoD should be established for:

• Each sprint/iteration.
• Each feature or epic.
• A release (Definition of Releasable).

Essential Test Information

A tester in an Agile environment needs continuous access to the following information:

• The specific user stories or features prioritized for the current iteration.
• Well-defined acceptance criteria for each story.
• System architecture, API contracts, and interface specifications.
• Details of the target deployment environments.
• Availability and configuration of test tools and frameworks.
• The agreed-upon test coverage goals (e.g., linked to risks, requirements).
• The current Definition of Done (DoD).
• Access to CI/CD pipelines and build artifacts.

Given that testing in Agile is a continuous and collaborative effort, not a sequential phase, testers are responsible for:

• Proactively seeking and clarifying test information throughout the iteration.
• Identifying information gaps that could impede effective testing and working with the team to resolve them.
• Collaboratively deciding on the appropriate scope and depth for different test levels within an iteration.
• Ensuring that relevant tests are executed at the optimal times, providing rapid feedback.

Modern Functional and Non-Functional Test Design

Agile projects leverage established test design techniques but emphasize early testing and continuous feedback. Test cases, or at least test scenarios, should ideally be defined before or in parallel with development (e.g., via ATDD/BDD).

For Functional test design, testers and developers often use black-box techniques such as:

• Equivalence Partitioning
• Boundary Value Analysis
• Decision Tables
• State Transition Testing
• Use Case Testing / User Story Testing

For Non-Functional test design (e.g., performance, security, usability), these requirements are typically part of user stories or defined as separate NFRs. Testing strategies include:

• Early performance testing (e.g., component-level, API load testing).
• Security testing integrated into the CI/CD pipeline (e.g., SAST, DAST tools).
• Usability testing with representative users or heuristic evaluations.
• Accessibility testing against standards like WCAG.

Consider leveraging API testing tools (e.g., Postman, REST Assured, Karate DSL) and contract testing (e.g., Pact) especially in microservice architectures.

Exploratory Testing

In fast-paced Agile environments, formal test case design for every scenario can be time-prohibitive. Exploratory Testing (ET) is a powerful complement, defined as simultaneous learning, test design, and test execution.

During ET, the tester designs and executes tests dynamically, using insights gained from the application’s behavior to inform subsequent tests. This is highly effective for discovering defects that scripted tests might miss and for adapting to frequent changes. Structured approaches like Session-Based Test Management (SBTM) can bring focus and measurability to ET.

Risk-Based Testing

Risk-based testing (RBT) is crucial in Agile to prioritize testing efforts where they matter most. It involves identifying potential product quality risks (functional, performance, security, etc.) and assessing their likelihood and impact.

Risk analysis helps prioritize testing activities within time-boxed iterations:

• High-impact, high-probability risks demand thorough and early testing.
• Lower risks may receive less intensive or later-stage testing.

Test techniques are chosen based on the risk level and characteristics. The goal is to mitigate the most significant risks efficiently, ensuring the most critical functionality is robust.

Automated Acceptance Tests (ATDD/BDD)

Automated Acceptance Tests are a cornerstone of Agile quality. Practices like Acceptance Test-Driven Development (ATDD) and Behavior-Driven Development (BDD) help bridge the communication gap between business stakeholders, developers, and testers. They focus on defining executable specifications.

BDD frameworks (e.g., Cucumber, SpecFlow, Behave) use a human-readable language like Gherkin (Given-When-Then format) to define acceptance criteria. These specifications can then be automated.

Example of a Gherkin scenario:

Feature: User Login

  Scenario: Successful login with valid credentials
    Given the user is on the login page
    When the user enters valid username and password
    And clicks the login button
    Then the user should be redirected to the dashboard

These automated tests serve as living documentation and provide fast feedback on whether the system meets the agreed-upon behavior. They are typically run as part of the CI/CD pipeline. Tools like Selenium, Cypress, or Playwright are often used for UI-level acceptance tests, while API testing tools can automate acceptance tests at the service layer.