Sharing Product Requirements in Testing: Developing the Right Product.

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.

Funny product requirements
Funny product requirements

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.

cucumber specs

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.
Feature written in Cucumber style
Feature written in Cucumber style

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

Cucumber specs
Andrei Domuta

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.

About the Author

Andrei Domuta

Since my Master in Science graduation I have been working in the Software Testing field for projects varying from desktop applications to web platforms in both outsourcing and insourcing environments. I have been working for large companies like Siemens or Mozilla but also for medium-sized ones like Liverail (a Facebook company) or start-ups like q-leap. I’d love to have a chat on any topic related to testing and QA, so please don't hesitate to leave me a message. Cheers!
Find out more about @andrei-domuta