September 2, 2016 in Test Automation
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
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.
May 24, 2016 in People/Skills
The theme of EuroSTAR 2016 made me reflect more on the role of a tester. For testing professionals the topic of “learning to test, testing to learn” makes sense, since we already know that testing involves continuous learning about what is being built but for some other people this is not easily understandable. So, I came up with an explanation to the question ‘what is the role of a tester’ so that even a seven year old can understand. It is based on the famous story of Noah and the devastating flood.
One can imagine that Noah gave the following instructions to his shipbuilder sons: ‘soon there will be a devastating flood so we need an ark that is big enough to shelter two of each animal species on earth and our families’.
Building An Ark
When it comes to gathering all the animals of the earth into one place one should consider quite a few things not just the shapes and sizes, as the shipbuilders might have thought. Like the fact that male giraffes are taller than the females and they should both be able to go through the same vessel entrance. Or the fact that lions and antelopes should not be put close to one another.
One can imagine that the shipbuilders were advised by a girl who would know many things about animals if two animals can have spaces next to each other or not. Or, if the shipbuilders needed to check if an elephant fits into a space, a boy would help and arrange some stones so the stones would match the shape and size of the animal. Of course the shipbuilders could not have known and done these, because they were too busy building the ship.
Role Of A Tester
So, whenever something is built, whether if it is a ship or a software, there has to be someone that is focused on the hidden details of the requirements and who constantly learns new things, like the girl in the story or someone that can check if it works without having the real environment available, like the boy. And these are, in fact, the key attributes of a tester. They make the role of a tester invaluable to any development team.