Test-Driven Requirements: beyond tools
Executable requirements looks like a great technique, just as using tests as specification sounds like a great idea. These techniques and concepts are radically changing the way software can be specified and produced in agile teams. On the other hand, FIT has been out for a while and no big revolution in software development happened (yet?). Was FIT only “another nice tool” to support agile development ? Are we expecting better tools to start the revolution ? Or did we just miss the point of using tests for defining requirements ?
The objective of this session is to put collaboration on top of any test-driven requirements initiative. Many organisations focus on implementing tools like FIT/FitNesse from a testing point of view, trying to make use of the many different table formats provided in order to specify as many tests as possible, thinking that, tables being more readable than code, subject matter experts with no technical background will adopt the tool. This session will put an emphasis on building specifications using tests that really capture examples provided by the user or product owner. No tool will be used so as to avoid limitations and constraints related to specific tools.
The session is divided into 2 parts.
First Part: “Highlight the problem” exercise (30 mins) In this exercise, 4 persons (or 4 small teams) will participate to a communication game that will bring the communication problems at the front of the scene: one is the user, one is the product owner, one is the development team, and one is the so-called independant validation team. The exercise is divided into 4 steps:
1st step: the user makes some construction using blocks that the 3 other teams are not allowed to see (e.g. they will be out of the room)
2nd step: product owner enters the room and is allowed to see the finished user’s construction
3rd step: development team and validation team enter the room but are still not allowed to see the user’s construction (it will be hidden by some device), and they will not see the product owner either (they will be back to back for instance). The product owner then describes the construction to the development team who has to reproduce it the same way (NB: the product owner cannot see what the development team is doing). The dev team is given the same set of blocks as the client used (we can make the game harder by giving more blocks). The validation team on its side cannot see either of the constructions (user’s one and dev’s one). It should writes acceptance tests for the construction based on the description of the product owner.
Last step: the validation team looks at the development team’s construction and tells whether it meets user’s construction (they’ve still not seen the user’s construction).
This exercise is not meant to just highlight the communication problems, the audience will try to identify patterns of communication regarding how examples are used to support descriptions in a natural and spontaneous communication.
Second part: “best practices” workshop (60 mins)
The audience will be divided into small teams to work on a case study. Each team will encompass different roles of a software development projects. One mandatory role is the user, who will be diffusing the business needs based on interactions with the other roles. Each team will try to write specifications, using tests for capturing real user’s examples or business requirements. This will last approximately 30 mins. The other 30 mins will be a retrospective in which:
every team will show its result and explain the choices they made,
every participant will give his feedback about the exercise and will try to identify best practices for doing test-driven requirements.