...

The methodology Test Case Designer facilitates is based on the research results about the causes of defects in production. Manually written test cases often represent a very fragmented view of the system, focusing on individual inputs while allowing redundancy or omissions in the remainder of the scenario. On the contrary, Test Case Designer provides complete control and traceability for each of the steps in the test case.

While the question posed above is reasonable, Agile vs Waterfall is not the best classification criterium for applying Test Case Designer. The same is true for dividing the apps into GUI, non-GUI, micro services, etc. – it also does not align well with the Test Case Designer strengths.

It is a test design optimization tool which focuses on the early stages of the testing process and then integrates with tools responsible for the subsequent steps, like Ranorex Studio. Speaking about the reduction of effort, the goal of applying Test Case Designer is to deal with such challenges of manual test creation as prolonged and error-prone scenario selection, gaps in test data coverage, tedious documentation, and excessive maintenance.

The methodology Test Case Designer facilitates is based on the research results about the causes of defects in production. Manually written test cases often represent a very fragmented view of the system, focusing on individual inputs while allowing redundancy or omissions in the remainder of the scenario. On the contrary, Test Case Designer provides complete control and traceability for each of the steps in the test case.

The tool can deliver significant benefits across project and application types, as long as their functional flows demonstrate sufficient interaction variety.

Thus, the key app characteristic is flow variations – in other words, the system overall should contain several decision points and at least 2 steps in the process with multiple options per each. Higher number of those creates numerous possible paths through the system, therefore Test Case Designer could be applied to identify the optimal set to test them.

...

You can refer to the diagram below for the high-level applicability decision tree.

Although the application type is not the decisive factor for Test Case Designer applicability, the table below illustrates “happy path” examples for each category.

...

An application with numerous parameters (e.g. >=8) and values may not be a good fit for Test Case Designer if the interactions between the elements are heavily limited, leaving only a few possible paths through the system.

Test Case Designer Case Designer Place in Agile

Next, let us focus more on how applying Test Case Designer is different in the Agile environment. To have an anchor/benchmark, in the waterfall world, by the time you reach testing, most information is well-defined, so you can start moving through all the traditional Test Case Designer six steps sequentially.

...

The key challenge is that not every user story may be applicable (from the number of inputs & variations perspective) and, consequently, not every sprint may have sufficient scope. It is quite common that Test Case Designer is used in every 2nd or 3rd sprint, once the testing model has enough elements to justify the combinatorial exploration. And of course, once it comes to regression for each release, Test Case Designer models can be easily updated to accommodate the new functionalities.

It is also worth noting that sometimes a user story does not look applicable but thinking outside of boundaries will quickly change that assessment. For example, if a user story specifies the ability to log in correctly, it looks like a test with 2 parameters, 1 value each. However, if we look deeper, that requirement means a correct login for different allowed formats for usernames and passwords and an incorrect one for invalid options. Suddenly, thoroughly testing a simple user story can fully leverage Test Case Designer capabilities.

Test Case Designer as a Catalyst for BDD

At this point, it is also important to keep in mind the general role of the tool in BDD practices (which often accompany the Agile transformation). When we consider common BDD goals, we can think of these 3 as being important:

...

From the automaton standpoint, model-based testing allows easier maintenance and reusability while writing Give-When-Then scripts inside the tool helps less technical users to contribute more to the creation of automated tests.