📖 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?

📖 Who wants what and why? The original meaning of a user story

We have all seen them. Gigantic Jira user stories, filled with extensive specification, a truckload of screens for every conceivable device type and a list of things that are supposed to be acceptance criteria. But, regardless of all the available information, in the end the programmed solution deviates significantly from what the stakeholder really wanted. How is this possible? Why does this happen? How can we do better?

📖 Saving time by using the IDE's linters and formatters

How should code be indented - with tabs or with spaces? Should the indentation be two or four spaces wide? Should the opening curly brace be on the same line as the function declaration or on the next line? Should there be an empty line before each return statement? Should “yoda” conditions be allowed or even enforced? Should unused variables be deleted?

With each of those questions you can fill whole tech talks. But does it make sense to discuss these questions in your team? Does it make sense to define custom rules, just for your project? Is it worth the time and effort? Will it save you time or money in the future? Will the code quality be better compared to just using the standard linting settings of the IDE? Let’s explore the idea.

📖 Gherkin vs Cucumber vs BDD - What is the difference?

The terms Gherkin, Cucumber and BDD are closely related. They mostly appear in the same context, but they are distinctly different things and cannot be used interchangeably. In discussions, online articles or even in big test management tools they often get mixed up.

If you try to find “Gherkin alternatives” in your favorite search engine you will be presented with many Cucumber alternatives, but nearly no results for Gherkin.

The test management tool “Xray” - a 3rd party plugin for Jira - is also a bit sloppy when it comes to the wording. You can switch the “Test Type” to “Cucumber” to then enter a “Gherkin” scenario into the input field below!?!

Another common misconception is when people write tests in Gherkin and then think they are doing BDD. Spoiler alert: this is (often) not the case.