Testing in Scrum

Question

In Scrum it's a good idea to test frequently when iteration is finished at customer. But the question is what kind of test should I use when some of the prototype is done with customer? In my knowledge Acceptance test is ok when all the iteration is done - but not some part of it. Examples for the test plan would be helpful

Answer 1

Presumably the prototype was to demonstrate something (performance, a particular slice of functionality, etc) - you therefore should be developing the equivalent acceptance tests with the code.

In other words, lets say you are doing a prototype that shows how you will process a million messages a second in the full application. As well as writing the code to do that you should also be working out how, when it comes to end of iteration, you will get the customer to sign off that yes the software does indeed process that many messages.

As part of the early demo you should be talking through both the code and tests with the customer.

Also remember in Agile/Scrum testing is a continuous process not just something you save up as an end of iteration activity.

Answer 2

In Scrum, you always have a fully working product (which means you have tests that make sure the product does what it should). The product may be missing a few key features (or all of them when you're in the first iteration) but your goal is to forget the idea of "prototype" and start thinking in terms of "all code is always production ready".

There is an exception: The technology spike. Here, you develop a small demo (which is again fully functional but very limited) when you try to learn a new technology. Most of the time, you will refactor this code into the final form (instead of simply throwing it away and starting from scratch).

This article might help to understand this idea better: Prototypes by Clinton Keith.

Answer 3

The trouble I find with the word "test" is that it assumes that the functionality you're developing is the right stuff.

If you're prototyping to show to a customer, try working from the basis that everything you're doing is wrong, and you want to find that out as quickly as possible. Finding out that it's what the customer wants will then be a nice surprise. Your test should be to get feedback from your customer, and you want to get a failure or two before you get a success. If your customer is just nodding and saying "Yes, that's fine," then you might have the wrong customer ( here's something I wrote which might help: http://lizkeogh.com/2010/02/02/theyre-not-user-stories/ ).

I also use BDD's scenarios to talk to BAs and users about what we expect to happen, so that the prototype itself stands a better chance of being good.

My prototypes are usually unit-tested code with hard-coded data behind them, rather than hacked-together pieces that need to be thrown away afterwards. The GUI's the complicated bit and the part that's most likely to change anyhow (I don't unit-test GUIs).

Hope this helps!