“Could Test Case Designer still be applied, given iterative nature of requirement generation and uncertainty about the final state of the features?”
In this article, we would like to discuss related applicability concerns and dive deeper into the benefits Test Case Designer (TCD) could deliver in the Agile environment throughout SDLC.
First, let’s talk about broader Test Case Designer applicability
While the question 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, microservices, etc. – it also does not align well with the Test Case Designer's strengths.
It is a test case design optimization tool that focuses on the early stages of the testing process and then integrates with tools responsible for the subsequent steps. Speaking about the reduction of effort, the goal of applying a 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 based on the research results about the causes of defects in production. Manually written test cases often represent a fragmented system view, focusing on individual inputs while allowing redundancy or omissions in the remainder of the scenario. On the contrary, the Test Case Designer provides complete control and traceability for each test case's steps.
The tool can deliver significant benefits across project and application types if their functional flows demonstrate sufficient interaction variety.
Thus, the key app characteristic is flow variations – in other words, the system should contain several decision points and at least 2 steps in the process with multiple options per each. The 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.
| Application Category | Use Case Description | Sample Model as an example |
|---|---|---|
| GUI Functional | A customer-facing web calculator with a mix of 4-5 text fields, dropdowns, and/or radio buttons (not counting the environment variables like device/browser). The business rules require testing multiple combinations of inputs and their effect on the rating outcome. | "Personal Loan Calculator - Automate" |
| Non-GUI Functional | A customer-facing microservice for digital payments which allows you to perform multiple payee-related operations (such as "get"). The request structure for that operation includes 3+ fields with multiple values each. The combination of those fields directly affects the response file. | Reach out to us for the customized sample. |
| GUI Field/Element Visual Validation | An employee-facing dashboard where the UI positions of elements need to be checked for various roles. Alternatively, an application with repetitive objects (header, footer, links, etc.) needs to be verified on multiple pages. | Reach out to us for the customized sample. |
| Non-GUI File Validation | An application is responsible for processing files and producing an output, where combinations of the file format and the output location need to be tested. | "ETL Testing Example" |
The use cases discussed so far demonstrate the applicability only from the perspective of inputs. While that is often the primary factor, it is important to consider other elements:
Positive Influence:
- Script Length
The minimal models (2×2) make more sense if the script contains 10+ detailed steps with data-driven expected results. Manual copying of the script always has room for error.
- Output Format and Standardization
Creating a model in Test Case Designer may be the fastest route to get the Xray, Gherkin, Java, etc. file with the test cases. Further, you guarantee the consistency of the export format across projects.
- Application Growth
The current release may have minimal information, but if the application keeps growing, you may want to get ahead of the curve and start building the Test Case Designer model in advance.
Negative Influence:
- Excessive Constraints
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's 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.
On the contrary, the iterative nature of the Agile process can be illustrated in the following diagram (Source):
Test Case Designer usage flow should ideally start as early as Sprint Planning and requirement definition. SMEs can leverage domain knowledge and application access to more accurately specify the inputs for each requirement. Then the majority of the work is performed during Sprint Execution. Testers would pick up the draft models and expand them to the execution-ready state at the acceptable coverage level. Finally, data tables would be exported to Ranorex Studio, or manual scripts would be exported to Xray, or automated ones (in the BDD format) would be passed to the coders for adjustment based on the automation framework.
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.
If the two features come in different sprints, it would likely be necessary to wait until the second enhancement (if there are no other parameters known from the previous releases or the application access/documentation).
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. 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:
- Early Stakeholder Communication
- Clear and Thorough Software Requirements
- Accelerated Automated Testing and Maintenance Efforts
From the communication standpoint, reviewing the testing efforts at the model level (in tabular or mind map format) and analyzing the coverage with the help of visualizations should help reach a mutual understanding faster.
From the requirements standpoint, Gherkin already facilitates a more clear understanding of those. On top of that, Test Case Designer provides the platform for people with 3 knowledge components (technical, business, and functional) to come together and make sure ambiguities are eliminated, and each requirement clearly specifies all the critical input values.
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 contribute more to creating automated tests.
Conclusion