Specification By Example – BDD for Pragmatists
For the product to get a good position in the conditions of the modern IT market, we, developers, need to achieve two goals. Make the right product (exactly what the market wants to buy) and make the product right (without spaghetti code, bugs and other technical issues).
The right product and product made right are not the same thing!
Failure to fulfill the first condition will lead to a financial collapse, which means that it is likely to close the project. Failure to fulfill the second – to the fact that one day we will find ourselves waist-deep in the f … code. Probably, it is not necessary to explain all the “benefits” of legacy-system support without tests and specifications.
Specification By Example is a process that allows you to regularly achieve both points. The process is based on agile, tdd, bdd, continuous integration and test automation.
Key elements of Specification By Example:
- Deriving scope from goals
- Specify collaboratively
- Illustrating using examples
- Refining the specification
- Automating validation without changing specification
- Validating frequently, evolving a documentation system
Deriving scope from goals
The vast majority of people are able to formulate what they really need. In most cases, you will encounter the fact that the client will formulate the requirements not in the form of “I have a goal, how can we achieve it?”, But: “make me a something nice like a neighbor has, but with pearl buttons”. The client will tell you how he sees the solution to the problem, and dive deeper into the implementation details.
Here is the first and most important mistake. Usually one and the same problem can be solved in several ways, and in the form of requirements we already receive a request to implement one of the possible solutions. But not all solutions are equally useful.
Our task as engineers is to offer a solution better and cheaper than the client asks. This principle was formulated by Henry Ford:
“If I asked people what they want, they would ask for a faster horse.”
Fighter F-16 – one of the most successful fighters in the history of the US Army. The initial development requirements were to reach Mach 2-2.5 speed, which combined with other requirements made the development and production of such an aircraft was very expensive. Harry Hillaker – the leading designer of the F-16 – clarified why this speed requirement is so important, and received the answer: “the aircraft must quickly fly away if it gets really hot.” Hillaker proposed an alternative solution and designed a fighter, superior at that time to others in terms of maneuverability.
More than 30 years have passed, and these fighters are still in production. 4400 aircraft sold in 25 countries. On the F-16 actors fly in most Hollywood films: from Independence Day to Transformers … As well F-16 still cannot reach a speed higher than Mach 2.
The F-16 is so successful because the engineer offered the solution better and cheaper than the client requested.
Pay attention to goals, not go straight to the decision. There are many ways to achieve the goal.
How to highlight the main thing
Albert Einstein once said:
“Formulating a problem is often more important than solving it.”
Before coding, make a specification. Yes, we, the developers, do not like pieces of paper, formalism and multi-page files that no one reads in the end. But think about how often you blamed someone who made the requirements and acceptance criteria. Take responsibility and make the specification yourself in the form in which it will be convenient for you to work.
Here are some examples of unsuccessful items that fell into the specification:
- All pages should be displayed in 0.1 seconds. The word “all” should be avoided in the specification in general. Yes, the homepage should open as fast as possible. But you will spend weeks or months trying to get into this framework a summary report that runs once a year. Such rare and resource-intensive operations can take a long time. Nothing wrong with that.
- The user-interface should look like OSX. Fashion has created thousands of sites with the replacement of native controls, and with them the pain of thousands of programmers and web developers. Let the interface look like OSX on the Mac and in the Safari browser. On other systems, leave the native controls.
- There should be a flash banner on the main page of the website. Perhaps this banner doesn’t need a flash at all, and everything can be done using html / css / javascript, and you already have a similar module out of the box. Avoid overclarification of technological aspects in the specification.
Use user-stories
User-stories are one of the best ways to understand what is really needed. User-stories can be formatted a little differently, but must contain 3 points:
In order to – why?
As a – who?
I want – what?
Having worked through each such story, you will be able to understand whether you really need what you are asked for, or if there really is a better solution to the problem that no one just thought about. If I want is already formulated, but As a and In order to are not, this is an occasion to think. Perhaps you are going to develop functionality that nobody needs.
This may look like user-stories of spamming programs for increasing the loyalty of an online store:
- In order to be able to do direct marketing of products to existing customers,
As a marketing manager
I want customers to register personal details by joining a VIP program.
- In order to entice existing customers to register for the VIP program,
As a marketing manager
I want the system to offer free delivery on certain items to VIP customers.
- In order to save money,
As an existing customer
I want to receive information on available special offers.
Specify collaboratively
A specification made alone, without a team, is the second big mistake and potential space for misunderstanding and subsequent edits. Instead of relying only on one specialist, involve the entire team in the preparation of the specification. If you work on scrum, a meeting is a great time to do this.
Developers better understand the infrastructure and know the technologies that can be applied to solve the problem. QA specialists will indicate in which places errors may occur. Product-owner is an expert in the subject area. All of this information is useful for compiling specifications. Collaboration allows you to:
- Better deal with the problem and find the best solution.
- Make the whole team understand the new requirements equally.
- Involve all participants in the process.
At the planning stage, it is better to connect the entire team. After the main front of the work is clear, pair work or small meetings for 3-4 people are more effective in order to clarify the difficult points.
Want to know more? Stay tuned for the next part of the article and contact our developers team for any further information!
Related Posts
Leave a Reply Cancel reply
Service
Categories
- DEVELOPMENT (102)
- DEVOPS (53)
- FRAMEWORKS (25)
- IT (24)
- QA (14)
- SECURITY (13)
- SOFTWARE (13)
- UI/UX (6)
- Uncategorized (8)