An agile testing glossary to help you navigate the terminology

Agile testing has its own vocabulary, and understanding it is essential for anyone working in or moving into a testing role within an agile team. Key terms like sprint, definition of done, shift left testing, and three amigos describe specific practices and agreements that shape how testers contribute to delivery. Knowing what they mean helps you engage more effectively from the very start of each iteration.

This glossary covers the agile testing methodology terms you are most likely to encounter day to day, explained in plain language and organised by theme. It is designed as a practical reference for testers at any stage, whether you are new to agile development or looking to sharpen your understanding of the concepts your team uses.

Core agile concepts every tester should know

Before getting into testing-specific practices, it helps to understand the foundational agile methodology concepts that shape how teams plan, prioritise, and deliver work. These terms come up constantly across sprint ceremonies, backlog conversations, and day-to-day collaboration in software development.

Agile, sprints, and iterations

Agile is an approach to software development that prioritises collaboration, flexibility, and the delivery of working software in small, frequent increments. It is guided by the Agile Manifesto, published in 2001, and most modern delivery is based on frameworks such as Scrum, Kanban, or SAFe.

A sprint is a fixed-length period of work, typically one to four weeks, during which a team delivers a defined set of functionality. Testing in agile development is expected to happen within the sprint, not after it. The broader term iteration is often used interchangeably with sprint and simply refers to a single cycle of development that builds on the last.

Backlogs, user stories, and acceptance criteria

The product backlog is a prioritised list of all the features, enhancements, and fixes a team intends to deliver over time. User stories are the primary way requirements are expressed in agile teams. Written from the perspective of the end user in the format “As a [user], I want [goal] so that [benefit],” they form the basis for test design.

Each user story should come with acceptance criteria, which define the conditions it must meet to be considered complete. Testers should be involved in defining and reviewing acceptance criteria before development begins, as they set the scope for testing and provide the foundation for test cases. Understanding how user stories translate into testable requirements is a core quality assurance skill in any agile team.

Epics, definition of done, and definition of ready

An epic is a large body of work that breaks down into multiple user stories, typically representing a significant feature or capability spanning several sprints.

The definition of done is a shared team agreement about what it means for a piece of work to be truly complete, covering development, testing, code review, and any other quality checks required before release. The definition of ready describes the conditions a user story must meet before the team commits to working on it, which from a testing perspective often includes having clear and testable acceptance criteria.

Agile ceremonies and how testers contribute

Agile delivery is structured around a set of recurring ceremonies that give teams the opportunity to plan, collaborate, inspect, and adapt. Testers who participate actively in these sessions have far more influence over quality than those who wait for work to arrive.

Sprint planning, standups, and reviews

Sprint planning takes place at the start of each sprint. The team selects work from the backlog and agrees on what they will deliver. Testers should participate actively, raising questions about clarity, risk, and testability before work begins.

The daily standup is a short meeting, typically fifteen minutes, where team members share progress and flag blockers. It is a key touchpoint for raising testing concerns early. At the end of the sprint, the sprint review involves demonstrating working software to stakeholders, gathering feedback, and adjusting priorities for the next sprint.

Retrospectives, three amigos, and backlog refinement

The sprint retrospective is a team reflection held after the sprint review. Testing quality, automation coverage, and defect trends are all valid topics. Small process changes agreed in retrospectives often have a meaningful impact on how smoothly the next sprint runs.

The three amigos is a collaborative conversation between a business analyst, a developer, and a tester, aligning on what needs to be built and tested before work begins to reduce ambiguity and rework. Backlog refinement is the ongoing process of reviewing and improving items in the product backlog. Testers who participate in refinement sessions can spot missing acceptance criteria and raise risks before stories reach the sprint, which is one of the most valuable contributions a tester can make to agile software development.

Agile testing concepts and practices

Understanding the specific testing practices associated with agile delivery is central to working effectively in these environments. These concepts describe how and when testing in agile development happens, and the techniques that support quality throughout the life cycle.

Shift left testing and exploratory testing

Shift left testing refers to testing earlier in the development life cycle, ideally from the moment a requirement is written, rather than waiting until development is complete. It is one of the most widely used agile testing principles and reduces the cost of finding defects while improving the quality of the final product. If you are exploring software testing courses to build your skills in this area, shift left thinking is a core part of modern test practice.

Exploratory testing is a simultaneous process of learning, test design, and execution. Rather than following a predefined script, the tester uses judgement and knowledge to investigate the software dynamically. It is particularly well suited to agile environments where requirements evolve and scripted tests cannot cover everything.

Regression testing, TDD, and BDD

Regression testing in agile checks that existing functionality still works correctly after changes have been made. In agile delivery, where code changes frequently, regression testing is a constant concern and agile automated testing plays a key role in keeping it fast and sustainable.

Test-driven development (TDD) is a development practice where tests are written before the code they validate. Behaviour-driven development (BDD) extends this approach by expressing tests in plain language that non-technical stakeholders can read and contribute to. Scenarios are typically written in a Given When Then format, and tools such as Cucumber are commonly used to implement BDD, bridging the gap between business requirements and automated tests.

Continuous integration and continuous delivery

Continuous integration (CI) is the practice of frequently merging code changes into a shared repository, with automated builds and tests running each time. CI CD pipelines help teams detect integration issues and defects quickly, keeping the codebase in a releasable state.

Continuous delivery (CD) extends CI by ensuring that software can be released to production at any time. Agile automated testing is central to continuous delivery, providing the confidence needed to deploy frequently without manual regression cycles. Together, CI CD is among the most important technical practices for testers working in modern agile teams to understand.

Estimation, velocity, and testing metrics in agile

Agile teams use specific approaches to estimation and capacity planning that differ from traditional project management methods. Understanding these helps testers contribute meaningfully to sprint planning and ensures testing effort is factored into what the team commits to delivering.

Story points are a unit of estimation used to reflect the relative complexity and effort of a user story. Velocity is a measure of how much work a team completes in a sprint, expressed in story points, and is used for forecasting rather than as a performance metric. Testing metrics in agile, such as defect escape rate and test coverage, give teams additional insight into quality trends across sprints.

Risk, quality, and informal agile terms

A few additional agile testing types and concepts are worth understanding, particularly those relating to quality, risk, and the informal language that emerges in experienced agile teams.

Risk based testing and technical debt

Risk based testing in agile is the practice of prioritising test effort based on the likelihood and impact of potential failures. In agile environments where time is always constrained, risk based thinking helps testers focus on what matters most in each sprint rather than attempting exhaustive coverage of every scenario.

Technical debt refers to the accumulated shortcuts and compromises made during development that will need to be addressed later. From a testing perspective, technical debt can manifest as untested code, fragile agile automated testing suites, or missing coverage in legacy areas of the system. Being able to identify and articulate technical debt is an increasingly valued quality assurance skill.

Done done

Done done is a more informal agile term that refers to work which is not just functionally complete, but fully tested, reviewed, and ready for release, meeting every element of the definition of done without exception. It is a useful shorthand in team conversations for distinguishing between work that is technically finished and work that is genuinely ready to ship.

Building your agile testing capability

Understanding agile testing methodology is a starting point rather than a destination. The real value comes from applying these agile testing principles in practice: participating actively in ceremonies, collaborating on acceptance criteria, thinking about risk from the beginning of each sprint, and contributing to a culture of continuous improvement.

Testers who engage with agile processes from the outset, rather than waiting to receive work at the end of a sprint, become genuinely valuable members of their delivery teams. They influence quality at every stage of the life cycle, which makes a measurable difference to the software that reaches users.

Our agile training courses and software testing courses are designed to help testers build the skills and confidence to work effectively in agile environments, whether you are new to agile development or looking to deepen your practical understanding of agile testing methodology.