Page History
...
First, let’s talk about broader Test Case Designer applicability
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 servicesmicroservices, etc. – it also does not align well with the Test Case Designer's strengths.
It is a test case design optimization tool which that 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 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 is based on the research results about the causes of defects in production. Manually written test cases often represent a very fragmented system view of the system, focusing on individual inputs while allowing redundancy or omissions in the remainder of the scenario. On the contrary, Test the Test Case Designer provides complete control and traceability for each of the steps in the test case's steps.
The tool can deliver significant benefits across project and application types , as long as if 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 The higher number of those creates numerous possible paths through the system, therefore Test . Therefore Test Case Designer could be applied to identify the optimal set to test them.
...
| 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 rate rating outcome. | "Personal Loan Calculator - Automate" |
| Non-GUI Functional | A customer-facing micro service 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 where the with repetitive set of 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 current release may have only the 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.
...
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):
There, Test 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.
| Info |
|---|
If the two features are coming 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 from 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. Suddenly, thoroughly Thoroughly testing a simple user story can fully leverage Test Case Designer capabilities.
...
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 the 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 to contribute more to the creation of creating automated tests.
| Info | ||
|---|---|---|
| ||
| Thus, the focus of your decision-making should revolve more around the universal benefits of Test Case Designer and whether those could improve your status quo. |
...