─ Discover Quality ─
Software engineering is hard.
Typing code is the easy part.
Doing it in a way, so that the code is stable, readable, maintainable, testable, performant, and is actually doing what
the stakeholder expects it to do, is the difficult part.
Achieving good software is only in parts a technical problem.
It is important to make sure that everyone involved has understood the requirements and that everyone has the same
understanding of them.
In general, that requires multiple discussions and therefore good communication skills.
At first glance, this sounds like the job profile of a product owner (or manager), but it is the responsibility of the
whole team (Dev, PO, QA, Stakeholder, etc) to achieve this shared understanding.
My weapons of choice are BDD, Cypress and Jira/Xray.
BDD gives us the tools to create the shared understanding and to extract a reliable list of acceptance criteria.
With Cypress, it is very easy to convert those ACs to automated end-2-end tests.
And with the Jira plugin Xray we get a powerful test management tool, which directly connects the tests with the
requirements, giving us a high level of transparency.
In this blog I will share my experiences with those tools and frameworks.
There will be some hands-on articles and tutorials on how to use them correctly.
And there will be articles, that are more on the theoretical side, in which I discuss the ideas and concepts behind
quality assurance in the modern software engineering world.
You can start your reading here.
Latest articles
📖 Evolving a Gherkin scenario
Even a well written Gherkin scenario can still be improved.
Have a look at the following example.
It describes a customer who wants to buy alcohol in an online shop.
Given the customer is an adult
When the customer adds a bottle of whisky to the cart
Then the checkout process should allow the customer to buy the whisky
✅ The scenario is short.
Seb Rose and Gaspar Nagy recommend five steps or fewer. [1]
✅ It is easy to read and to understand, therefore supporting the shared understanding aspect of BDD (Behavior-driven Development). [2]
✅ It describes the intended behavior, not the (incidental) details - a vital element to “good” Gherkins.
For example, it does not describe how the whisky is added to the cart or how the checkout process is initiated. [3]
✅ It doesn’t mix different rules or acceptance criteria.
Everything that is not essential to the scenario is ignored.
Things like availability (Given the article is in stock) or address information (Given the user has provided a valid address) are important aspects, but not here.
This supports the “focus” rule in the BRIEF pattern. [4]
So, objectively this is already a good Gherkin scenario.
It checks many boxes.
There is nothing obviously wrong with it.
But, we can still do better.
📖 How to measure the test coverage of user stories in Jira?
Creating code coverage reports is easy these days.
For every major programming language there exist tools that can analyze which lines of code have been touched by the
unit tests – and which were not.
With the help of these reports it is easy to find gaps in the test coverage and to locate dead code.
Getting a feature coverage report is much harder.
A code coverage tool doesn’t know anything about the features and how they are connected to the code or to the tests.
A project management tool on the other hand has all the information about the features, but has no clue about how they
are linked to the tests.
In this article we will discover what is - in general - needed to generate such a feature coverage report.
And you will learn how it can be implemented in Jira, how to manage the user stories, requirements and acceptance tests,
how to come up with a useful coverage metric and how to actually visualize the numbers.
📖 Is the test pyramid compatible with BDD?
The test pyramid is a popular metaphor to describe how the testing efforts should be distributed in a software development project.
It recommends having many unit tests, some integration tests and a few end-2-end tests.
One of the motivations behind BDD is to create a living documentation, usually described with Gherkin scenarios and implemented with Cucumber tests.
Those Cucumber tests are often seen as the tip of the testing pyramid.
But is this a valid assumption?
