code's life

Probably you are playing with agile for a while and notice some problems for testing and requirement handling, then I want to recommend “Specification by Example”

Let’s start with problem

Problem in requirement handling and testing

Testers are used to follow and verify the implementation

In traditional software development, it is pure waterfall, system level define the requirement, and testers write test specification on how to test it, designers are implementing it. After the coding is finished, the live system is verified by testers according to the test spec.

When we turns to agile way of working, mostly this model will be kept without change, some teams even use small waterfall inside the team.

Lots of technical debts come out in end of each iteration because there are gaps between testers’ understanding and designers’ undestanding, then people are used to complain on the requirement.

In the same time, tester’s motivation is used to be low, they just simple verify what has been done. Some senior testers used lots of method to make sure all the bugs can be found, which is great.

BUT do we testing the right thing ? !!!

No practical way to clarify the requirement

Some sites may run agile better, they invited PO frequently to clarify the requirement, and had PBR “Product Backlog Refineworkshop” meeting (see Craig & Bas’s book “Practices for Scaling Lean & Agile Development”). While this is just the framework, people mostly had problem how to make it effiency, and how to get the requirement and make it clearly.

ATDD doesn’t work

When quick scan the “Specification by example”, most people will treat it is the same as ATDD and BDD, while in the book and his workshop, he clearly stated,” yes, they are quite similar, and there are more mind-set changes for SBE”.

The importance of SBE is to the practical way to clarify the specification by examples, here are the key process patterns, I used to use this pursuide my colleagues

Some tips to deploy Specification by Example

it cannot be described easier in one blog, let give some tips that I used if you want to try

Start without tool

I made this mistake before as well, since mostly we will use tool to support your automation (this is good, but tough task), therefore I didn’t make ATDD works in my product.

It is quite easy to focus on automation instead of clarifying the requirement when you deploy it, so start without tool.

In my pilot, I just ask the testers (they are trainined for this concept for sure) to write specification with what SBE suggested, put the business value inside instead steps.

Understand the tool, but it is not necessary

People are used to lost why do this in this kind format, so you need to understand some tools to see how it can be automated to execute the specification and automate it easily.

There are lots of nice tool, like cucumber (http://cukes.info/), which is most popular and useful tool, and I push team members to write in its format.

Fitnesse and RobotFramework are good, but I don’t recommend, since they are built long time ago, it can support SBE, but they are not generated by SBE concept, while cucumber do comes from that.

Can do it as well for your products

People are used to say, “yeah, it works for web application, but our product is different”, it is not true. The way to clarify the requirement is the same, surely it may be more difficult and not so straight, but it do works.

You can read his book as well for some patterns.

Start with small and you can get benefit directly

Summary

I list some benefits so far for my consultant service on this area after 1-2 months (surely other practices are applied as well)

1. Testers get more motivation than before, since they drive the requirement clarification and notice the importance the role inside the team, they drive what to implement
2. Requirements are easier to be clear compare to before, therefore the technical debt from this is gone, less waste.

Therefore, I do suggest

• Buy this book or at least read some free excellent sample chapters from manning to understand it, if possible, join his workshop
• Try it and it can work from day one, trust me.

Tags: cucumber, Specification by Example

This entry was posted on Wednesday, December 28th, 2011 at 11:18 pm and is filed under Agile. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.