Agile Testing

As new and better software development ways are being uncovered, the following holds much value i.e.:

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

 Two key imperatives underlying these values are: 

Work Code

A general thumb of rule is that programmers are more comfortable getting on the computer and getting it to do something, than writing documentation.  Similarly, Agile believes in the Hands-On Imperative and extends it even to users.  Why?  Because, most mental activities need external resources, with different resources making us think in different ways.  And, that is why people who document or design models, think differently from those working on software.

Because, Agile projects understand that, they deliver working software (or perhaps executable proto-types) as quickly and as frequently as practical.  Development is a rapid series of functionally complete releases the user can try out.  Each release being the first chance a user’s had to think about new features, means re-work on the release is just part of the job, not a crisis. 

Open Communication

With little or no documentation, Agile projects keep everyone in synch due to increased human contact i.e. face-to-face conversation and collaboration.  XP has people programming in pairs, with most often a customer representative working most days in the bullpen with the developers.  Scrum holds daily stand-up meetings that create and preserve group understanding.  Crystal, perhaps the least dogmatic process conceivable, nevertheless insists on frequent retrospectives.  All these techniques tend to foster communication that documents cannot replace.

And, since all Agile methods want a customer to be part of the team, with a suitable customer representative on hand, one does not require a detailed requirements document.  You have a question, simply turn around and ask it!  Worried the right question won’t be asked?  Well, you can implement something and show it to your customer for a quick reaction.  Without much ado about nothing, you’ll quickly learn if you’re going off track. 

Agile Testing

These same imperatives can also underlie Agile Testing, and most obviously apply to Agile development projects.  However, they work, though less well on conventional projects, as well.

But, first abandon the idea that communication is about one party communicating with requirements and design documents, while the other comes back with test plans and bug reports.  You know full well that documents tests are based on are flawed i.e. incomplete, incorrect, and ambiguous and to be viewed only as interesting texts, partly fictional, often useful.

Agile testing communication should be all about joining in and encouraging ongoing project conversation.  Testers and developers need to sit in the same bullpen or share offices.  Testers should be made help particular developers, rather than just testing how pieces of the product work.  ‘Drop-in meetings’, short, informal discussions, etc. help in test status reports via big, public, simple-to-read charts that answer specific development questions, such as, which product parts are working well.

Communicating with the customer is as important as communicating with developers, as more often than not, the customer is trying to figure out what is needed, what they want, whether they are getting it.  And, they can only do this by testing the working code and talking to the developers and testers.  Testers should sit down with them as try out the product sample, as creating tests together is an excellent way for both to learn what matters.

Hands On helps developers improve and complete the product and value tests they can run as they develop.  While, Agile Testing may not be the answer to all projects, neither are any of the Agile Methods.  Acutally, no single approach is, but experimenting with different project styles is essential if a standardised software development practice is to be arrived at.