lördag 22 oktober 2011

Agile Testing - Test early

A common feature on many scrum boards is a column with the title “Test” or “Verify” or perhaps “Acceptance”. This column is almost invariably towards the right hand end of the board. Implement first, test afterwards. Does that sound agile or are we just making the same old mistakes?

Once you've got your testers in the team, and teaming up with the programmers, it's time to get serious about testing early. Not just early programmer testing but early customer testing too.

Having a separate column for verification on your scrum board merely reinforces the traditional idea that testing is something you start doing when a feature is implemented.

You don't have to wait until features are complete before starting work on customer tests. And if you can successfully encourage testers and programmers to work in harmony you might even find that a feature is tested and accepted at the same time that the implementation is completed.



söndag 16 oktober 2011

Agile Testing – Teaming up

Interesting things happen when you start using Test Driven Development. One revelation is that TDD isn't just about discovering bugs:

"The act of writing a unit test is more an act of design than of verification." (Bob Martin)

As I previously wrote, a first step towards agile customer testing is bringing your testers into the team. A second step is to encourage your testers to team up with programmers and work together on the development of features.

As we have brought testers into our team and encouraged them to team up with programmers we have also seen benefits that aren't just limited to finding bugs.

To paraphrase Uncle Bob:

The act of writing a customer test is more an act of process improvement than of verification.

So what are these process improvements? Here are a handful we have experienced:

  • Stories get broken down into smaller stories that allow the testers to get testing early

  • Customer tests define the features of the product, eliminating the need for many of the documents traditionally associated with testing

  • There is no need for a separate acceptance activity – when the programmers have completed the feature the customer tester has completed their testing

  • Programmers get involved in, and a better understanding of customer testing (and vice versa).

I'm sure we will discover more benefits as we get better at customer testing.

måndag 10 oktober 2011

Agile Testing – The embedded tester

It's the obvious first step towards agile customer testing – bring the testers into the team.

There is certainly a risk that a tester will lose their objectivity when they become part of the development team. But would a good tester allow this to happen? Would an alert agile coach allow this to happen? Surely not.

Being an embedded tester means changing how you work. Instead of merely diagnosing bugs after they've become chronic, you can help to prevent bugs from infecting the product in the first place.

An agile tester doesn't have to be the person who just ticks off features against a list of requirements. They can, and should be much more than this. Working in the team the tester can take a much more active role in improving the product and influencing the development process. They can help build quality into the product rather than trying to test quality into it.

Not all testers find it easy, or are prepared to adapt to this change in approach. But it's not unreasonable to demand a degree of personal agility of your agile testers.

Success has it's foundation in people. So if you're serious about agile customer testing, make sure you have the right testers in the right place. In the team.



måndag 3 oktober 2011

Agile Testing – Simple in practice

Agile developers know that a few basic practices can be used to drive simplicity into programming. Working in collaboration with the customer simplifies communication. Pair programming reduces the need for documentation and controls. Programmer testing drives you towards a simpler design.

So what are the practices which can be used to drive simplicity into agile customer testing?

Face to face communication is the simplest and most effective way for us to communicate, by a long chalk. So bringing the tester into the team is an obvious way of bringing programmer and tester face to face.

Another practice to simplify testing is encouraging testers to team up with the programmers - it's not just programmers that can make a pair. For the more open minded, why not try a threesome – programmer/programmer/tester? You'll find you simply don't need a lot of the documents that are traditionally required when testing.

Finally you can start customer testing early. Whether it's automated testing or exploratory testing, you shouldn't need to wait until the end of the sprint to perform them. And by encouraging the programmers to break up large features into smaller ones the tester can drive the team to deliver features that are simpler to test.

So there you have it – three basic practices to simplify agile customer testing:

I'll stick my chin out and suggest that these are defining practices for agile customer testing. There are several other good practices that agile testers can adopt, but if you're not doing these three then you're not agile testing. It's as simple as that.