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