What is Agile testing?

Although Agile testing occurs at every stage of the development life cycle, an effective Agile testing strategy incorporates its own life cycle, made up of four distinct stages:

Often referred to as "Iteration 0", the initial stage of Agile testing covers the groundwork that will be needed to push tests forward. This involves establishing a business case, scope and boundaries for the project, while also outlining key requirements, identifying risk and performing cost estimates. It also includes identifying and securing essential testing resources (including people and tools).

Most Agile testing occurs during this stage. Construction iterations are repeated testing actions that may be classified as either confirmation testing or investigative testing. Confirmation testing verifies that the function or product fulfils the established purpose it was designed to address. Investigative testing locates bugs or other issues not directly tied to product purpose, such as usability or integration defects.

As the project nears completion, Agile testers must validate the completed software as a whole. This includes full-system testing and acceptance testing, and is generally much more rigorous than mid-development tests.

Finally, with testing complete, the product can move into production.

As they become more proficient at Agile development, many organisations prefer to create their own Agile testing methodology to better match their unique needs. Still, it often helps to start with an established methodology and then adapt it to specific use cases. The following are several popular approaches to Agile testing:

Test-driven development (TDD) places tests at the very beginning of the Agile development process. Tests are created for each functionality and are then run. If the program fails the test—which it will because the code for the feature has not been written yet—developers then write the simplest code possible to make the test pass. Automated testing scripts help instruct developers to write code only when tests fail, eliminating the risk of duplicate code.

Acceptance test-driven development (ATDD) is similar to standard test-driven development. The distinguishing factor is that ATDD starts with the creation of a customer story. Teams dial in on how the product is to be used and then create a user-acceptance test to help guide development. This approach places user expectations at the forefront of the development cycle.

A natural extension of ATDD, behaviour-driven development (BDD) also begins with the creation of a user story. However, that story needs to be connected directly with a business outcome, specifying why—from a business perspective—the feature is being developed. Tests are then built to drive development in the direction of the desired business outcomes.

While automated testing scripts are employed in TDD, ATDD and BDD testing methodologies, exploratory testing takes the manual approach. It relies on human testers to generate relevant tests as they explore the developing product. Although not as structured or as fast as the testing methodologies listed above, exploratory testing makes full use of tester skill sets and intuition and is effective at locating risk-related issues that would slip past other approaches to testing.

Session-based testing takes exploratory testing further. Rather than relying so heavily on the tester's instincts, it adds structure by which tests may be conducted. At the beginning of each session-based test, testers create a charter, detailing exactly what the team hopes to discover with the test. This is followed by a focused, uninterrupted test, after which the test is reported on. By starting exploratory tests with a clear goal in mind, testers can ensure that no areas get overlooked.

Agile testing provides for many different approaches and types of tests, which can make it difficult to determine which tests are most appropriate in which circumstances and whether manual or automated testing is the better approach. To help guide their development teams, many businesses rely on Agile testing quadrants.

Agile testing quadrants provide essential testing taxonomy — teams can quickly determine what kind of code to write by looking at the two left-hand quadrants and learn more about the code they've written in the two right-hand quadrants. The four quadrants are as follows:

This quadrant includes tests that exist to improve the code and the product. They are generally automated and are performed throughout the app development life cycle, with the purpose of providing developers with feedback on code quality.

The second quadrant is dedicated to tests that help to improve the business outcomes of the product. Combining manual and automated scripts, these tests help to ensure that the product does what it is supposed to and drives value for both the business and its customers.

Providing feedback on tests in the previous two quadrants, Quadrant 3 consists of user-acceptance, usability and exploratory tests. These manual tests exist to test both the product itself and the user experience, and to give developers vital insight into the product to ensure that it can fulfil its designated function.

Quadrant 4 involves tests related to the non-functional requirements of the product, such as data security, stability and compatibility. These technology-facing performance tests rely on tools capable of automating the testing process.

Together, these quadrants offer a holistic view of software testing to help inform decision making. They do not, however, provide a means to prioritise tests — those decisions must be made by the teams themselves.