While both beginners and experts can easily make minor changes to tests, these activities take up a great deal of time and are error prone. All changes can affect dependencies between tests and their artifacts. As a result, seemingly small changes not only threaten productivity: They also can be responsible for a test project breaking down.
To solve these productivity and accuracy issues, QiTASC developed disQover, a model-based testing (MBT) tool that is compatible with intaQt and all other QiTASC test automation software. The disQover UI turns models of Flows into suites of test cases, which can then be executed via intaQt Studio or intaQt Client.
disQover models cover not only the steps of a test case, but configurations, input parameters and decision points to ensure the optimal combination and number of test cases are created. Importantly, the tool also enables users to:
- Make changes to models, which are then instantly applied across entire intaQt projects
- Store models as templates, allowing them to be adapted and reused in other projects
- Avoid human errors, because disQover restricts the models to follow a logical and correct test case structure
- Challenges in Manual Test Case Maintenance
- Manage Test Cases with disQover: Basic Flows
- disQover Feature: Discover How to Manage Products Better, Faster and Reliably
- What are the Benefits of Using disQover?
- Conclusion & Contact
A common pain point associated with test case maintenance is that it takes a long time to apply small or large changes to a project, and ensure that they are both accurate and don’t interfere with dependencies such as configuration files or Feature Files. This can arise, for example, after a new requirement is added or when a bug fix has been introduced. Manually changing each test case can take days or even weeks. This can be especially problematic during time-sensitive phases where any delay can threaten a project’s success.
For example, let’s say that we’re running a project that tests a login mechanism for different user types, including one with an expired account:
Feature: WebtestFeature Scenario: WebtestScenario Given a firefox browser as MySession When on MySession, I try to login: * username is expiredAccount * password is 1234 Then my login fails with "Your account has been deactivated."
On the backend, custom functions may construct the website, its elements and the actions performed on them. Additionally, it’s likely that these tests include other activities such as HTTP and SSH authentication, accessing customer databases and calculating data usage. Each of these activities adds layers of complexity and dependencies between different components of a test case.
These interdependencies mean that making even a small change can create a chain reaction of problems across a project if done incorrectly. For example, it might become necessary to differentiate between two types of
expiredAccountWithCredit, depending on whether or not the expired account has a credit left on their account.
In the following section, we’ll demonstrate what such changes would entail, and how managing them differs significantly from the manual approach and when using disQover.
Manually Changing Configurations and Feature Files
Using the login example, what happens when we split
expiredAccountWithCredit? The first issue is that the old login might have been mapped to configurations that:
- Define user logins and passwords
- Map users to tariffs or charging patterns
- Create authentication tokens for usernames
- Enable notifications to phone numbers or email addresses linked to usernames
In order to manage our project, we may need to adjust all of the criteria described above to reflect the two different types of accounts. However, changing configurations can be risky. For example, assigning an account to a new tariff that doesn’t allow credits on expired accounts could affect other test cases in a project , resulting in failures when the newly-configured account needs to be used for other tests. Additionally, we need new test cases for each of the two user types.
If both account types need the same set of tests run, a common manual approach would be to change the account assignment in all Feature Files to
expiredAccountNoCredit, duplicate each test case, then change the account assignment for each duplicate test case to
expiredAccountWithCredit. Other consequences and time-consuming activities related to manually making minor changes to projects might include:
- Going through Feature Files to double-check and change account assignment steps
- Running trial-and-error test cases to check if the changes in account assignment was done correctly
- Comparing new test requirements to spreadsheets outlining different test cases and their parameters, then:
- Finding the tests that need to be changed
- Applying changes to each test
- Updating the spreadsheet to reflect the changes
Our login example shows how regular project maintenance can use up a lot of resources. These manual efforts increase exponentially as a project grows in size, especially as bug fixes are made, new requirements are introduced and additional steps, models or activities are integrated into tests.
This is where disQover becomes a powerful tool for test teams: disQover models Flows, which represent tests, including all potential choices and outcomes. Next, these Flows are converted into test cases that represent each possible combination of steps derived from the model.
If we were to use the original login with hardcoded values, the disQover Flow might look like this:
In disQover Flows, the shapes are assigned parameters. For example, the
Open Browser step may accept a parameter with three choices: Chrome, Safari and Firefox. Assuming
Login only contains one username and password as parameters, and the
Verify Login also only contains one potential outcome as parameter, disQover would generate three Feature Files from the Flow, where each Feature File executes the same steps using one of the three defined browser parameters.
Although this Flow is quite basic, if the
Verify Login parameters were also populated with multiple values, such as different usernames/passwords and login messages, disQover would again generate a Feature File for each potential combination.
However, if we want to try different login types that generate different login messages depending on the user type, a better practice is to extend the Flow by adding a few more shapes.
Manage Test Cases with disQover: Expanded Flow
The above Flow models a login test that opens a browser, logs in and verifies the login. However, this Flow doesn’t allow for much variation. Using the same scenario, where two types of
expiredAccount parameters need to be introduced, we’ll extend our Flow by adding some Decision Points.
userName, we added a Decision Points, which allows for control flow. The Decision Point branches out to Subflows according to the input parameter. In our case, the one parameter,
userName, contains three different choices:
expiredAccountNoCredit. Depending on which username is applied to the test case, a different path will be taken so that different user types will reach different login outcomes and messages.
After applying the changes to a Flow, disQover automatically propagates (or applies) the changes to the whole project. It updates existing Feature Files and applies the changes to intaQt Studio, while sending new ones directly to intaQt Studio where they can be immediately executed. This means that instead of the three Feature Files we originally had (one test case for each browser type), we will now have nine Feature Files, allowing for all possible combinations of configured login types and browsers.
While the manual efforts to adapt these tests could take hours, disQover allows such project-wide changes to be completed in a matter of seconds or minutes.
disQover’s efficiency and accuracy comes from its concise set of features that let users focus directly on maintaining test cases without worrying about dependencies, human error or time-consuming manual activities. The application’s Web-based UI contains three main components:
- Shape Management, which selects shapes and defines how they map to the steps of a test case
- The Model Editor, for creating, editing and tweaking new or existing model Flows
- Test Planning, which applies configurations to Flows and provides inputs to render intaQt Feature Files
Manage and Configure Shapes
The disQover Shape Management feature includes a pre-populated shape store, which makes selecting the correct shapes intuitive and straightforward. Shapes are selected depending to their function, such as Activity or Effect, and mapped to steps defined in Shape Management. One of the feature’s key benefits is that once a shape has been created, it can be used multiple times in a single Flow or in multiple Flows.
Visual Model Maintenance
The Model Editor implements shapes made with the Shape Management tool to create a Flow. By demonstrating a test case Flow in a clear and concise manner, it allows for visualizing and creating test scopes. Here the user can define input and output parameters for each shape.
Reusable Test Planning
The Test Planning component implements configurations for Flows with Decision points or Plugs, and lets users indicate exactly which path to follow. The Test Planning feature is especially useful for test cases with multiple Plugs and/or Decision Points. Rather than creating new test Flows for each outcome, the same Flow can be reused and only relevant criteria and configurations need to be changed. Upon clicking the
Add to test scope button, all Feature Files created or adjusted by disQover are sent to intaQt.
Simply put, disQover scales up test case management as well as test case creation. In doing so, it saves hours’ worth of manual efforts spent on checking code, comparing test cases against project documentation, and troubleshooting errors from newly-introduced parameters or modules. Some of the key benefits are described further below.
Save Time by Instantly Applying Changes to Entire Projects
While user-friendliness and simplicity were important when developing disQover, the main goal was to tool that could instantly apply changes across projects with a few clicks. Although intaQt Studio users can use features such as
rename refactor across projects, refactoring is only suitable for renaming objects. On the other hand disQover goes beyond just renaming: When applying changes from a disQover model, like in our example above, all dependencies such as configurations, input and output parameters get automatically updated too.
Reuse, Duplicate and Tweak Existing Models
Once a model has been created in disQover, it is stored as a template that can be accessed, copied into a new model, and adjusted for new projects. This makes it great for:
- Multi-phase projects, where all backend functionality (for example, custom models, configurations) stay the same, but slightly different variations of Feature Files need to be created
- Running several similar projects at the same time, such as multiple apps or webpages, where only elements such as XPaths need to be changed
In all cases, accessing an existing disQover model and reusing it as a template eliminates hours or days of work spent creating each test case. Instead, the user only needs to update dynamic parameters, such as a browser’s identifier or how long to wait on a certain page before proceeding to the next.
Be Confident that Your Tests are Stable and Error-Free
While intaQt Studio already provides productivity features to help users avoid making human errors, disQover takes protection against mistakes even further. By creating models that are converted into intaQt-compatible test suites, disQover’s internal modeling framework automatically ensures that all test cases conform to requirements that keep them error free from common problems such as:
- Typos and spelling mistakes
- Unresolved models and functions
- Ambiguous, incompatible or conflicting steps
- Relative path and configuration errors
Easy Abstraction for Knowledge Sharing
The difficulty of understanding or using complex models and functions for both experts and non-experts is a frequent pain point in test automation. disQover’s Flows were created specifically with different user types in mind, meaning that anyone can look at the visual representations and understand what they mean with little or no explanation. As testing increasingly requires cross-departmental communication, ensuring people from diverse professional backgrounds can share a common understanding of how a test scope is model and maintained was a top priority for QiTASC developers.
One of the most complicated and time-consuming parts of a test project is all the work required to create and maintain test cases. This is because test planning maintenance has largely remained a manual activity within the scope of test automation.
By introducing disQover into the QiTASC toolbox, intaQt users now can create, change and maintain projects of any size with just a few clicks. This saves hours of time spent on manual efforts and prevents human error by restricting Flows to logical, useable scopes. A standout feature of disQover is its reusability, where all models are stored as templates and can be accessed, reused and adapted for future projects. As projects progress over time, subsequent projects therefore take less and less time to set up and maintain.
In addition to disQover’s standalone functionality, it is fully compatible with all other QiTASC products:
- intaQt, which enables test execution via intaQt Studio and intaQt Client
- conQlude, QiTASC’s automated reporting and defect management service
- sQedule, the resource-aware scheduler that automates test prioritization, execution and device management
As for technical knowledge, disQover is quick to learn and easy to abstract. However, the best way to get familiar with disQover is by experimenting with it and finding out how useful it is yourself!
Are you looking for a way to turn test management into a hassle-free, quick and reliable activity? Get in touch or check out the disQover Product Page to learn about our demo version that will help you “discover” the better way to manage tests.