Activity-based Requirements Engineering Quality Meta Model. An artifacts has certain properties (quality factors), which have an impact onto activities, which are conducted by stakeholders.

Requirements quality is quality-in-use

I’ve worked quite some time on understanding and detecting quality defects in requirements documents and requirements quality in general. All the time, I was very dissatisfied with the current state in both research and practice on this topic. I think, the problem behind this is that there is no guidance: In times of rapid change and delivery, where every project looks different, we still have no good rule of what a good requirements document is.

A few years ago, we came up with such a rule, and tried it in various applications. And – so far – it seems to work! We’ve collected this experience and are now ready to tell you about it, because we really believe this should change how you view requirements engineering, and this should change what you consider good requirements documents.

Continue reading Requirements quality is quality-in-use

Conditionals: Why you should avoid these two letters for better test case execution

At Qualicen, it’s often my job to check other people’s system test cases and tell the team what I think about these tests. So what do I look for? Well, in principle it is simple: After tests are written down, they are “only” executed and maintained. So this is where tests can be bad and I try to spot things that make execution and maintenance harder. For the maintenance, the largest problem here are clones, which we covered in our last blog post. For the test execution, the main problem that you want to avoid is that different testers test different things. This is called ambiguity and comes in many tastes. In this blog post, I want to explain what is structural ambiguity and why it is bad, and this way help you to create better test cases.

(Scroll to the summary, if you don’t care about the details) 😉

Ambiguous test flow

The problem for test execution that I want to discuss here, is an ambiguous test flow. This means, that for a single test case, there are multiple paths that a tester can follow when she executes the test. Let’s look at an example.

A simple, straight-forward natural language system test case.

A simple, straight-forward natural language system test case.

Continue reading Conditionals: Why you should avoid these two letters for better test case execution