Automated Test Design

Automated Test Design

Goal: Apply business-related rules to combinatorial methods to avoid repetitive, cost-ineffective, and manual maintenance of automatically-generated test sets.

Let’s face it: Nothing is perfect. Life is messy, outcomes are uncertain, people are irrational, and relations (especially in test case design) are complex.

As you might have already experienced, even small test sets are often overloaded with countless business-related dependencies between attributes and instances. Well, the number (and nature) of these dependencies aren’t necessarily so troubling during the initial test case creation because business experts are often supporting you at that point. However, if these business experts move on, this knowledge also moves on. As a result, the maintenance of even a small set of test cases becomes a complex when information must be added, deleted, or somehow modified due to some change in the application or business logic.

The Problem

The problem stems from inadequate documentation as to why each test case was created. After the business experts move on, you’re left with only the details of what needs to be tested. You lack details about the origin of an individual test case— which makes it hard to adjust or re-create it.

Tricentis addresses this problem through a concept called test design relations. It enables you to define rules between attributes and instances. These rules are then considered in the course of an automated test case generation process that can be triggered by combinatorial methods.

With test design relations, you define rules to create test cases that wouldn’t have been created by any combinatorial methods. You can define rules that forbid the creation of certain combinations between attributes and instances in test cases, and you can define rules that constrain certain attributes and instances to each other. This not only prevents the creation of meaningless test cases in the course of an automated test case generation process; it also enables you to fill gaps in business risk coverage by creating test cases that wouldn’t have been created otherwise.

Since it’s repeatable, you can significantly reduce test case maintenance efforts (because no cost-ineffective manual clean-up of your test set is required for test cases created through an automated process). Additionally, your test set becomes living documentation that not only includes statements of what to test, but also explains why something has to be tested. As such, we bring meaning into automated test design.

Next: Risk Coverage Optimization
Back to AI in Testing Overview