Agile Testing

This article on Agile Testing assumes that you already understand Agile software development methodology (Scrum, Extreme Programming, or other flavors of Agile). Also, it discusses the idea at a high level and does not give you the specifics.

Agile Testing Manifesto

This is adapted from agilemanifesto.org and it might look a little silly to copy everything from there and just replace the term “development” with “testing” but here it is for your refreshment.

We are uncovering better ways of testing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Agile Testing Values

Individuals and interactions over processes and tools: This means that flexible people and communication are valued over rigid processes and tools. However, this does not mean that agile testing ignores processes and tools. In fact, agile testing is built upon very simple, strong and reasonable processes like the process of conducting the daily meeting or preparing the daily build. Similarly, agile testing attempts to leverage tools, especially for test automation, as much as possible. Nevertheless, it needs to be clearly understood that it is the testers who drive those tools and the output of the tools depend on the testers (not the other way round).

Working software over comprehensive documentation: This means that functional and usable software is valued over comprehensive but unusable documentation. Though this is more directed to upfront requirement specifications and design specifications, this can be true for test plans and test cases as well. Our primary goal is the act of testing itself and not any elaborate documentation merely pointing toward that goal. However, it is always best to have necessary documentation in place so that the ‘picture’ is clear and the ‘picture’ remains with the team if/when a member leaves.

Customer collaboration over contract negotiation: This means that the client is engaged frequently and is closely in touch with the progress of the project (not through complicated progress reports but through working pieces of software). This does put some extra burden on the customer who has to collaborate with the team at regular intervals (instead of just waiting till the end of the contract, hoping that deliveries will be made as promised). But this frequent engagement ensures that the project is heading in the right direction and not toward the building of a frog when a fish is expected.

Responding to change over following a plan: This means accepting changes as being natural and responding to them without being afraid of them. It is always nice to have a plan beforehand but it is not very nice to stick to a plan, at whatever the cost, even when situations have changed. Let’s say you write a test case, which is your plan, assuming a certain requirement. Now, if the requirement changes, you do not lament over the wastage of your time and effort. Instead, you promptly adjust your test case to validate the changed requirement. And, of course, only a FOOL would try to run the same old test case on the new software and mark the test as FAIL.

Principles Behind Agile Testing Manifesto

Behind the Agile Testing Manifesto are the following principles which some agile practitioners, unfortunately, fail to understand or implement. We urge you to go through each principle and digest them thoroughly if you intend to embrace Agile Testing. On the right column, the original principles have been re-written specifically for software testers.

We follow these principles:

What it means for Software Testers:

Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.

Our highest priority is to satisfy the customer through the early and continuous delivery of high-quality software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Welcome changing requirements, even late in testing. Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Deliver high-quality software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Business people, developers, and testers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Build test projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.

The most efficient and effective method of conveying information to and within a test team is a face-to-face conversation.

Working software is the primary measure of progress.

Working high-quality software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Agile processes promote sustainable development and testing. The sponsors, developers, testers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity–the art of maximizing the amount of work not done–is essential.

Simplicity–the art of maximizing the amount of work not done–is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

At regular intervals, the test team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The Recurring Question

So what happens to all the traditional software testing methods, types and artifacts? Do we throw them away?

The Answer

Naaah! You will still need all those software testing methods, types, and artifacts (but at varying degrees of priority and necessity). You will, however, need to completely throw away that traditional attitude and embrace the agile attitude.