Are we developing the right product?
A while ago, I saw a funny picture which was reflecting the communication issues between the software development teams. The picture consisted of a series of cartoons with titles like ‘how the customer explained’, ‘how the project leader understood it’, ‘how the analyst designed it’ and other. It was emphasising the different ways in which the software product is understood by the people involved in its creation process.
I did a quick search and found out that anyone can easily create a funny picture like that one. So for the purpose of this article I have created one that reflects the communication issues when it comes to creating and sharing information about product requirements or specifications.
Several times in my career I have encountered situations when the process of sharing the information about product requirements or specifications was flawed. Having a thirty-pages document (the SRS), focusing on how the system should look like and less on the behaviour can lead to developing, testing and delivering a product that is not what the business had originally in mind and nor what the users actually need.
Additionally, the people involved in building the product speak different languages (like business, testing, development) which leads to different interpretations if there are no clear rules on how to read the mammoth-sized specifications document.
Word Document or Cloud Collaboration Tool
On one project I worked on, in the early development stages, the Project Manager was asking every team member to read the specification pages for the new version of the product. We were not using Word documents but the Atlassian Confluence collaboration tool. After everyone read the specs, we would all gather for a Q&A session with the Business Analysts (who would be the authors). Based on our feedback, the Confluence pages would stay the same or get an update. Sometimes, there would be two or even three meetings like this until the information in the specs seemed to be clear enough for everyone.
However, whether presented in a Word document or a collaborative space, specifications that span over multiple pages and which are written in a language that is not easily understandable by all parties is basically the same thing.
The drawbacks of this way of writing specifications are obvious: finding information can be difficult, the use cases cannot be easily translated into code, it can be difficult to extract the test cases, updating requirements can be slowed down by the document review process.
Product Requirements in Testing
Luckily, some people came up with a good solution for sharing information about the product requirements or specifications which focuses on the behavior of the system rather than on how it looks like. Cucumber is an open-source tool which promotes simple, human collaboration which got its inspiration from Behavior-Driven-Development
Business and technical people don’t always understand each other because they use different languages (one using a more technical vocabulary than the other) and Cucumber reduces this gap by enforcing the use of the same language with the help of basic keywords like Given, When, Then, And.
The essential idea is to break down writing a scenario (or test) into three sections:
- The given part describes the state of the world before you begin the behaviour you’re specifying in this scenario. You can think of it as the pre-conditions to the test.
- The when section is that behaviour that you’re specifying.
- Finally the then section describes the changes you expect due to the specified behaviour.
The advantages of using Cucumber are numerous: there should be a single source for requirements and specifications, test scenarios and automated tests, the focus is on the user experience rather than on the system design, quick payback – faster scenario implementation and testing, a simple specs review-update process, test automation report reflect directly the specs (specs pass/fail)
Cucumber for everyone – not only for testers
At a first glance, Cucumber seems like a dedicated tool for testers. And I have personally seen the benefits of using Cucumber especially for test automation.
But I think it would be a great idea to have it as a single source to describe the behaviour of the product. And this would imply adoption across the entire project team. Which surely it takes time and effort to do so.
However, once in place, Cucumber would offer that tractability we are still missing between requirements, tests and the final product.
About The Author
I am an Engineer in Computer Science with a remarkable Software Testing experience. I have worked on projects varying from desktop applications to web platforms in both outsourcing and insourcing environments. I’ve worked for large companies like Siemens or Mozilla but also for start-ups like Liverail (now a Facebook company) or q-leap.
I am currently based in Luxembourg busy setting up the automation infrastructure and developing the test scripts at q-leap for Luxaviation’s management web-platform for private flights.
