“Lean” test specification

Many testers tend to do use the same test techniques for different problems. It could be that it is stated in a test plan or they just know one technique. It is not the way to go. In my opinion.

In my previous post on Lean specification I described the pull way of specification. This to get the better connection between the needed and actual amount of  specification. This can also be applied to testing to get a broader and better use of test techniques / test documentation.

We want only the tests to be done that are needed. Below you see again a picture with four quadrants. It looks like the one from Marick but it has a simpler approach.

Every User Story you map on one of the quadrants. Which has two axes one for impact (if this user story fails, how big is the impact) and how many time the user will use this function that will be available when the user story is created. The output is “documentation” that support the technique to be used.

The way I use the exploratory test charter it is a one page document that stimulate exploratory testing. No step to step (to precise) action or test good (to vague) It can be also seen as setting the mind in the correct state.  It has an execution time around an hour or two.

Automatic acceptance test is a fitnesse / robot framework / cucumber etc. test where is stated when to accept the sprint. And later they are used as regression test. The biggest advance I see is that it is an collaboration on what we concrete should create with examples.  Even if you don’t implement all the fixtures it already has and advantage.

Scenario are fully described step by step tests which can be handy but I try to avoid it. It is a lot of work. For error guessing there is no documentation but it can be very powerful in combination with exploratory testing.

The real power comes not from one techniques but from a good combination, where experienced tester will do this automatic. It can be a good way to verify if you does taylor on risk. If this rating is done with the team it makes it very transparent what is needed to be done.


About pascaldufour

Passionate Agile Tester
This entry was posted in Agile, Lean, Specification, Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s