“Nothing is perfect. Life is messy. Outcomes are uncertain. People are irrational. Relationships are complex.” – Hugh Mackay.

A truly wise statement, isn’t it? Relationships especially are incredibly complex when it comes to testing, or to be more precise: test case design.

What do we mean by relationship? We don’t mean an emotional or a sexual connection, neither do we mean an association by blood and marriage. As such, we are not talking about relationships, but relations.

So, what are the things that are related to each other? Instances and attributes in test case design.

But, why the heck is that worth mentioning at all?

As we, and maybe you, constantly experience in almost all test projects, even a small set of test cases is often overflowing with countless business-related dependencies between test case design attributes and/or instances. In fact, the number of these dependencies, as well as their nature, do not necessarily disrupt anything during the initial creation of these test cases, since business experts often act as supporting elements. If, however, these business experts move away, the knowledge moves away too. As a result, the maintenance of even a small set of test cases becomes a central issue when information has to be added, deleted, or mutated in the test cases due to some change in the application.

Does any of this sound familiar to you?

An unnecessary question, right? It is patently obvious that the principal reason behind this dilemma is due to the inability to adequately document the information why a certain test case is required. And so it is usually solely the information about what needs to be tested that remains. As a natural consequence, the origin of an individual test case can’t be traced back, so its creation can’t be reproduced anymore. In other words, some fundamental glue seems to be missing that holds the what and the why closely together. This is the bad news.

The good news is that all this has changed.

From now on the novel concept of test case design relations allows you to define dependencies between attributes and/or instances which are then considered in the course of linear expansion. It allows you to create additional test cases, to forbid the creation of certain test cases, and to constrain certain attributes and/or instances to each other. All this not only enables you to avoid unknown gaps in risk coverage, it also allows you to achieve the highest possible risk coverage on test case level. As such, the leak in risk coverage on test case level becomes visible for the first time.

That’s indeed a huge step forward isn’t it? As if this isn’t enough, it enables you to avoid the generation of meaningless test cases, which dramatically reduces maintenance, since no cost-effective manual clean-up of your set of test cases is required anymore.

Right down the line, a living documentation is provided through the test case design relations which not only includes statements of what has to be tested but also says why something has to be tested. Having all that said, it can be concluded that, from now on wards, the what and the why are certainly in love with each other.

Endnote. In conclusion, I am well aware that this article is by no means the most accurate article ever written on this topic. Rather it was my intention to provide at least a small foretaste to one of our numerous innovations in our brand-new release.

 

Download the Factsheet on Test Case Design Relations and Risk Coverage Optimization here!

Factsheet

Tricentis acquired Flood IO load testing - learn more

LEARN MORE
X