What is Agile Testing? Principles, strategies, and steps to run

For most software teams, delivering a top-notch product while keeping up with rapid development and release cycles can be pretty daunting. In such cases, agile testing can become a lifesaver. Rather than keeping testing activities on standby until development finishes, agile testing integrates the quality assurance (QA) and testing processes into the project as soon as it kicks off and into every development phase. Learn more about agile testing in this article.

Agile testing is a software testing methodology that uses the principles of agile development. In contrast to the traditional testing methodology (such as waterfall), where the testing activities start after the development completes, agile testing includes the testing activities in all phases of development — starting from the requirement gathering, all the way to the deployment and feedback phase. 

The key focus of agile testing is iterative and continuous product improvement. This enables teams to adapt the testing activities to the dynamics of an agile project. Moreover, with agile testing, quality assurance(QA and testers can catch software issues as soon as they arise and resolve them before they snowball to become larger defects.

Also Read: Quality Assurance vs Quality Control

Key principles of agile testing:

• Test early and often  — Instead of waiting for the whole build to finish, agile testing advocates for running the quality checks in all phases of the development cycle.
• Continuous delivery of valuable and working software — After each sprint, deliver continually improved and valuable software that satisfies users. This process continues throughout the development cycle.
• Collaborative work — Work collaboratively with the entire team (developers, QA, product owners, managers, business analysts) to shape and write suitable test cases, user stories, and acceptance criteria for the product.
• Quicker feedback cycles — Quicker feedback cycles help minimize response time from the key members (such as stakeholders, business analysts, and customers).
• Deliverables after each sprint — Software should work correctly with successful deliverables handoffs after each sprint (each sprint typically lasts for 2 weeks).
• Flexibility for scope changes — Adjust and adapt the testing activities to the changing requirements in an agile setup.
• Automate when possible — Develop automated scripts that are reproducible and can be run quickly with every build. For instance, in CI systems, every code change can trigger a suite of automated tests for validating the changes.

Also Read: Why every CI/CD pipeline needs a visual bug tracker

Agile testing quadrants are a 2D matrix-based representation that divides the agile development methodology for testing into four categories: Two of them representing the business aspects in agile testing, and the other two representing the technological aspects of it. Each of the quadrants includes specific types of testing in a typical SDLC.

The concept was first described by Brian Marick in the year 2003. It was then popularized by Gregory and Crispin in 2009 in their book “Agile Testing: A Practical Guide for Testers and Agile Teams”.

Purpose of the agile quadrants

Each quadrant helps balance the testing efforts in agile to ensure that the dev team’s requirements and the product market’s expectations are thoroughly vetted and validated for a top-notch end product.

Agile testing quadrants overview

The quadrants are split along two axes:

• Supporting the Team vs. Critiquing the Product
• Business Facing vs. Technology Facing

Here’s a breakdown of each quadrant:

• Quadrant 1 (Q1) — Technology-Facing Tests that Support the Team: Focuses on code correctness, verification, and validation. The purpose is to verify code through unit testing and component testing techniques using automation testing tools.
• Quadrant 2 (Q2) — Business-Facing Tests that Support the Team: Ensures that the software meets business requirements from the start, all the way through release. Includes functional testing, story tests, simulations, and prototypes. This one utilizes both manual and automated testing methods.
• Quadrant 3 (Q3) — Business-Facing Tests that Critique the Product: Focuses on testing and using the product, just as an end-user would in real-world situations, and getting feedback on its quality. Core testing methods covered: Exploratory testing, usability testing, user acceptance testing (UAT), and alpha and beta testing.
• Quadrant 4 (Q4) — Technology-Facing Tests that Critique the Product: Includes non-functional testing types, such as security testing and load and performance testing. The primary aim is to check the system’s stability and resilience under technical constraints. The Q4 typically relies on using professional expertise and tools.

Key strategies for agile testing:

1 - Test-Driven Development (TDD)

TDD uses the approach of writing the tests before the actual code is written and implemented. This strategy makes developers critically think about the expected output from the very beginning. Once the code is written, implemented, and ready to be tested, the testing activities start right off the bat to verify if the new features meet the project specs. 

Benefits of  TDD

• Improves code quality.
• Catches defects early.
• Fewer bugs in the later stages.
• Helps write maintainable, testable, and modular code.
• Integrates perfectly with the DevOps processes.

Example 

In an e-commerce app, if you are building a function to calculate discounts on orders, before writing the function, you create test cases for various scenarios: a standard order, applying a coupon, and an order that shows the best price after the maximum discount allowed. With TDD, you only write the code to pass those tests. This way, you can ensure that all potential cases are covered before the feature is delivered.

2 - Behavior-Driven Development (BDD)

With BDD, you can write test cases in plain language to describe the expected behavior of the software. This enables you to collaborate with both technical and non-technical stakeholders to define scenarios using a simple syntax.

Benefits of  BDD

• Facilitates better communication among all project members (technical and non-technical).
• Provides clarity on the business requirements explained through plain language. 
• Helps write test cases based on user behavior.
• Helps align business goals and testing activities.
• More involvement of the stakeholders, product owners, and business people.
• Facilitates automated acceptance testing for critical business features and user journeys with every build.

Example 

If you are testing a login feature in your app, in BDD, you would write a scenario such as: Given the user is on the login page, when the user enters correct credentials, then the user should be redirected to the dashboard. This clear language makes it easier for everyone to understand the expected outcome.

3 - Continuous Integration and Continuous Delivery (CI/CD)

CI/CD processes and tools can help automate test runs so that every code commit triggers a chain of tests that verify the functionality of the system.

Benefits of CI/CD in agile testing

• Reduces the number of merge conflicts as the project goes on.
• Fits perfectly with the automation testing processes.
• Shortens feedback loops.
• Keeps away the temptation to skip testing.
• Reduces risks at later stages by validating early on.
• Helps reduce unexpected rollback scenarios. 

Also Read: How to reduce rollbacks in CI/CD pipelines

Example 

If you use a CI tool like Jenkins or GitLab CI, you can automatically run your suite of unit tests and integration tests every time new code is pushed. When tests fail, the CI system alerts you immediately, allowing you to fix the issues before they accumulate.

4 - Exploratory Testing

While automation is key in agile testing, manual testing still matters, and there is an unwavering place for manual exploratory testing in the agile process. Exploratory testing enables you to use experience and technical expertise to test software to identify defects that automated tests might miss.

Benefits of exploratory testing in an agile setup

• Helps identify issues that could only be caught with human eyes and expertise.
• Does not require pre-defined test cases to get started.
• Helps test edge cases and unconventional scenarios.
• Helps lower the cost of overall QA since fixing bugs in production or at later stages is much higher.
• Replicate real customer behavior.

Example

After running a suite of automated tests on a new feature, you might use exploratory testing to navigate through the application just like an end user would. Then, you can check how the system behaves when you try unexpected sequences of actions or invalid inputs.

5 - Acceptance Test-Driven Development (ATDD)

ATDD is a collaborative agile practice where developers, testers, and business stakeholders jointly define acceptance criteria for a feature before coding. These criteria are framed as automated tests from a user's perspective, ensuring everyone understands what needs to be built and that the software meets user expectations.

Benefits of ATDD

• Ensures that all team members are on the same page and there’s no confusion.
• Focuses development on delivering business value and meeting user needs.
• Reduces ambiguity, leading to less rework.
• Creates executable specifications.

Example (Fund transfer)

• Success — Given accounts A ($500), B ($200). When transferring $100 A to B. Then A=$400, B=$300, transaction logged.
• Insufficient Funds — Given account A ($50). When attempting to transfer $100 from A. Then transfer fails, error shown, balances unchanged. These tests guide development.

6 - Session-Based Testing (SBT)

SBT is a structured approach to exploratory testing conducted in uninterrupted, time-boxed sessions (e.g., 90 minutes). Each session has a specific "charter" (mission) guiding the tester, who dynamically designs, executes, and documents tests, observations, and any defects found.

Benefits of session-based testing 

• Provides structure and focus to exploratory testing.
• Improves traceability and reporting of exploratory efforts.
• Uncovers defects often missed by pre-scripted tests.
• Encourages tester creativity and adaptability during testing.

Example (Advanced search)

• Charter (90 min) — Test advanced search with combined criteria (date, keyword, category); check results, performance, special characters.
• Process —  Tester executes various searches, logs bugs, and produces a project report for the session with details of coverage and findings.

Also Read: What is a requirement traceability matrix (RTM)?

The agile testing lifecycle is an iterative process that works using a set of pre-defined stages to integrate testing activities in every sprint as the development goes on. This leads to a continually improved product and provides the flexibility to adjust testing processes to align with the frequently updating requirements.

Key stages of the agile testing lifecycle:

1. Test planning — Key members of the team (stakeholders, developers, testers, business analysts) decide on the features to be tested in the sprint. Testing methods (unit testing, integration tests, and others), tools, and the acceptance criteria are planned.
2. Daily scrum meetings — Quick meetings are conducted by the Scrum master to take updates, monitor progress, and get a quick overview of the next day’s tasks.
3. Test agility review — Review of test results and getting feedback on the progress from the stakeholders.
4. Test release readiness — Ensure that the feature is release-ready and up to the expected quality standards.
5. Impact assessment — Access the business impact of the features.

Agile testing steps:

1 - Define testing objectives and acceptance criteria

Before the sprint begins, start things off by sitting down with your team and defining clear objectives for testing. This enables you and your team to work together to set acceptance criteria for the user stories and features considered to be tested in the current sprint. Use these criteria as a blueprint for your test cases.

Steps for it:

1. Review user stories with the product owner.
2. Note down all expected behaviors and outcomes.
3. Document clear, concise acceptance criteria.

For example, if you are testing an e-commerce checkout, ensure that acceptance criteria cover payment processing, error handling, discounts, and order confirmation.

2 - Create a testing plan for the upcoming sprint

During the sprint planning session, develop a testing plan that outlines what needs to be tested, how it will be tested, and the resources required. This helps organize your work and ensures that every aspect of the new code is verified.

Steps for it:

1. Choose the testing types you will use (unit, integration, UI/UX, performance, etc.).
2. Identify the tasks that require automation vs. manual testing.
3. Allocate time for regression tests and exploratory tests.

Your testing plan then becomes a go-to document that keeps updating through the sprint, as you add new test cases or update existing ones based on the feedback from earlier iterations.

Also Read: Unit Testing vs Integration Testing

3 - Develop and automate test cases

Next, work on writing tests that align with the predefined acceptance criteria. Wherever feasible, consider automating the test cases to make sure that they can run quickly with every build.

Steps for it:

1. Write unit test cases to cover individual code units or modules.
2. Write integration and functional tests for feature-level validation.
3. Use test automation tools whenever possible (e.g., Selenium for web UI, JUnit or NUnit for unit tests).

For example, if your application includes a login feature, you can write automated tests that simulate correct and incorrect login attempts. This can verify the functionality and serve as a safety net for future changes.

4 - Execute tests throughout the sprint

As the development cycle progresses, run these test cases repeatedly. Integrate automated tests into your continuous integration system so that every commit triggers the test suite.

Steps for it:

1. Run automated tests frequently (ideally with every code commit).
2. Continuously monitor test results and address failures immediately.
3. Complement automation with manual testing, especially for exploratory and usability tests.

These short, iterative testing and feedback cycles can ensure that the sprint’s code remains stable. Plus, the developers make the necessary adjustments as soon as issues are detected.

5 - Monitor test results and report defects

Next, collect and analyze results to identify any deviations from the expected output. Any issues found during testing need to be logged and discussed.

Steps for it:

1. Use a bug reporting tool, such as BetterBugs, and bug tracking tools (such as Jira, Asana, GitLab) to record each bug with clear steps to reproduce.
2. Discuss problems during daily stand-ups for everyone to be on the same page.
3. Prioritize fixes according to impact and severity.

For instance, if a test fails due to a login error, consider reporting it immediately with all relevant details, allowing developers to fix the bug without delay.

6 - Conduct regular sprint retrospectives

As each sprint concludes, join the sprint retrospective meeting to reflect on the process. This is your opportunity to assess what worked effectively and identify areas for improvement in your testing approach.

Steps for it:

1. Gather feedback from developers, testers, and other stakeholders.
2. Identify obstacles and blockers that prevented normal testing cycles.
3. Adjust your test plan for the next sprint based on the feedback.

This regular examination helps you refine your approach continuously. Over time, you can build a dynamic process that gradually eliminates repetitive defects and improves overall quality.

Read More: What are sprint retrospectives? Techniques and steps to run

7 - Adjust and refine test cases

As new challenges and requirements come up, make sure to adjust and refine the test cases accordingly. Don’t forget to update, add, or even remove tests to adapt to changes in the application and development methods.

Steps for it:

1. Review test cases after new functionality is delivered.
2. Learn from past bugs and update your tests to cover new scenarios.
3. Keep your test suite lean and relevant to avoid unnecessary test run cycles.