Quick Start

The test case is the foundation unit for Test Authoring. Think of a Test Case as one single atomic activity (with a group of actions that end-users need to perform) that achieves a unique functional goal.

In the above scenario, Story 3 and Story 4 require a flyer to benefit from the Loyalty Program or create/manage bookings. Both of these stories require users to log in. A new flyer must register and log in before they can avail themselves of these features. See how you can design Test Artifacts.

Note that Test Case 1, related to login, is common in both stories. Reusing this test case would improve efficiency and reduce maintenance effort.

As shown in the case above, test cases should be tied to the user's functional actions to achieve a meaningful outcome. That helps in modularity and reusability. The screenshot below shows you how to reuse this test case:

The “Validate that a flyer can log in” test case already exists for Story 3 above. You can reuse the same test case for Story 4 below. Reusing test assets in the event of repetitive user actions saves human efforts and keeps test artifacts in sync across the test documentation.

QMetry allows testers to organize and manage test cases in a Folder structure-based hierarchy. Test cases can be grouped according to test cases and organized systematically during authoring/post-authoring. A good organization of Test assets helps users find them more quickly.

Testers can create folders to group Test cases of one feature, module, or component. In QMetry, organizing test cases helps users carry out bulk operations such as associating test cases with stories and test cycles, moving/reusing them to other folders/projects, and so on. For example, you can group our FlyHigh project test cases feature-wise:

A custom field is an additional property defined for Test assets. QMetry provides most of the standard fields defined in the Testing process; however, sometimes, the stakeholders want to add custom fields to track the details at a granular level. QMetry allows QA Managers to create custom fields for Test assets to customize the entities according to their set Testing Process.

For example, in the test case, the QA manager wants to track a website's Feature and URL.

QMetry offers a strong reusability concept by allowing users to create a new version of the Test Case instead of updating it.

For example, as our airline website evolved, one more parameter was added to the login page along with a username and password. So, the Tester created a new version of a Test case with an added step instead of updating the original one.

When you want to cover multiple data combinations in a scenario, data parameters come into the picture. For example, when you write a test case for login.

The Test case is the same in these scenarios but requires different data. QMetry allows testers to create a set of Data with varying combinations using the Parameter feature.

A Test Plan should define the execution coverage to verify that the product or system is developed according to its specifications and requirements. In QMetry, a Test Plan is a group of test cycles. A Test plan can be created for a particular Sprint, Version, and so on. During the planning phase, a Test plan is created and multiple Test cycles are linked. This kind of grouping also allows easy tracking of execution progress.

Once the test cycles are linked to the Test Plans, users can track the execution progress of all test cycles on the test plan. It allows the QA manager to get a clear vision of the efforts required for testing.

A test plan can be organized into folders. For example, for each Release has multiple sprints. If a Test Plan is created for a Sprint, it can be organized in its Release folder.

During the test execution phase, a group of Test cases is linked to the Test cycles to test them against an environment, build, and so on. The test cases are assigned to a Tester for execution. Testers can create multiple executions for multiple environments, builds, and so on. Like test cases and test cycles can also be organized in folders and can have custom fields.

A. Grid View Execution Screen

B. List View Execution Screen

As a Test Cycle can have Versions and Sprints, the custom workflow statuses can be defined to match the workflow with Jira's workflow statuses.

The API is designed to upload the Test execution in QMetry. If you are using any of the following QMetry-supported Automation frameworks, you can upload your execution results in QMetry using QMetry Automation.

Automated Test cases are reused based on their Summary, Description, and Steps. Find a detailed description of how reusability works for different frameworks here.

QMetry provides multiple reports for automation.

The QMetry Open API supports almost all the operations that can be done manually on QMetry UI.