It’s been few weeks I attended a 3 days Advanced Agile Acceptance Testing workshop by Gojko Adzic at ThoughtWorks, Sydney office. I am trying to put down some points which I feel might be helpful for my friends.
What is Specification by Example
Specification by example is just the concept underlying our test driven development, in theory each test should indicate how a system will be used to build the software. Many times we think tool is important for making our life easier, but the fact is best of the tools,will also not help us unless we define specifications collaboratively correct and clear requirements with examples.
Most of the time teams blindly start implementing solution on the requirements which are given by the business, but in order to build the right software, we should define scope by derving it from goals and business should tell us the value they are looking for, delivery teams should use their knowledge and suggest a easier, faster and cheaper solution to the business.
Delivery teams should collaborate with business users in specifying the solution, each team members have their own capability and it can be leveraged, it also creates a collective ownership of specifications, making everyone involved and more engaged in the delivery.
Team starts writing these specifications using Natural languages so that it’s easier for other team members to understand, but they can’t be concrete in first attempt, which leaves a gap in understanding of the consumers mind because each individual perceives it differently, so in order to make it concrete, team should be using examples. Teams identify the key examples to fulfil a specification and later they can be expanded to cover other edge cases which testers find, in this way everyone in the team will share the common understanding of what needs to be delivered, which will avoid any kind of rework and since key examples are easy to understand and communicate, we can replace the requirements with these key examples.
Refine the specification
Now these key examples can be refined by cleaning them, by removing all additional information, they should only tell us what the software is suposed to do, not how it does. Once the examples are refined they can be used as an acceptance criteria, so when team is doing development they have to make sure that software works correctly for for all these examples. These key examples identified plays a various roles as acceptance test, functional regression test and specification of work.
Now in order to get the quicker feedback we automate these key examples and this way we reduce the cost of fixing the failing examples earlier. An automated specification with examples is written in a human readable format and should be easily accessible to all members of the team. We can use these executable specifications as a target for development and easily check if the system does what we agreed and the same document can also be used by the business when needed to change the specification.
Now since we have these specifications documented we should ensure that they are well organised, easy to find and consistent, when business rules changes these specifications should also be updated so that gradually they become a living documentation for the team.
Living documentation is a reliable source of information which tells us how the system functions currently, It is much easier to read and understand by any user, Business can use it as a reference for analysis of new requirement, Developers in the team can use it for development and we testers can use for the testing purpose.