When talking to clients about what agile means, I refer to values outlined in the often-cited Agile Manifesto.

The manifesto uses paired statements as a basis for describing the core ideals of agile. The specific nature of agile testing, however, lacks a community agreement to reference. Instead, I frequently explain the testing process to clients using my thoughts and experience.

I’ve now put these explanations in my own Agile Testing Manifesto, copying the style of the original industry manifesto. Since this is my first draft, I’d be grateful for your feedback in the comments section below.

Agile Testing Manifesto

In our efforts to build software of good and appropriate quality, we have come to value:

Collaborative ownership over detached objectivity

Defect prevention over defect reporting

Targeted automation testing over widespread anti-regression testing

Exploratory testing over predetermined scripting

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

Collaborative ownership over detached objectivity

When an external team tests your product, it has the benefit of being able to take an outside view. However external testers can’t quickly incorporate usability feedback into your business model like your own team can. External testers won’t be aware of the reasoning that takes place during development, nor will they have insight into the high-risk areas of the service, which consequently need the most testing attention.

To build a quality product, testing activities must be fully integrated with the development cycle. The same team that creates the product must do the testing. This ensures the whole development team owns the quality of the product, rather than one individual or role.

Defect prevention over defect reporting

Rather than being critical observers, testers must be actively involved in preventing product defects occurring in the first place. This is easier if testers are familiar with a product’s functionality and business domain, participate in development activities and work with business analysts and customers.

When product defects do arise, testers should either resolve the defects themselves or work alongside a developer to get them fixed. This will help the tester ensure sufficient tests are written to stop the defect arising again.

Targeted automation testing over widespread anti-regression testing

A full suite of anti-regression tests will ensure your products work as intended. These anti-regression tests are commonly performed at the end of a product development cycle. However, it’s far better to automate this testing so it’s a continual part of the development lifecycle, testing any functionality currently being developed.

Exploratory testing over predetermined scripting

Exploratory testing techniques give testers unrestricted freedom to test a product. They’ll use their prior testing experience to actively hunt down areas of poor quality in a product rather than methodically work through a predefined script. Testers must prove the software works for users, rather than only proving the software works as they intended.

What do you think? How can this Agile Testing Manifesto be improved?

Don’t forget to sign up to the Government Technology blog.