Overview
qTest Manager provides considerable flexibility in how you organize your Test Cases. As a user, you can change Test Case structure both from project to project and from release to release.
Note: Keep in mind that each qTest Project is its own separate entity, meaning each Project is fully customizable. For example, you can have a Project that integrated with Jira, and a Project that is not. No matter the integration status, each Project can be tailored to meet the needs of your team.
Organization
As a rule of thumb, try to organize Test Design so that it is easy to link Test Cases to Requirements for traceability, and to reuse test cases in the future. When it comes to organizing Test Design, the goal should be to have users able to add Test Cases for Execution quickly and easily. To accomplish this, try to keep the number of Modules and Sub-Modules (folders in qTest) to a manageable number. The more folders and sub-folders you have, the less efficient your Testers will be when adding Tests to execute.
Build your Test Execution structure so that it is easy to coordinate activities between different teams and look back at test log history. Ideally, test runs should be structured using the various hierarchies. In qTest the Test Execution hierarchy is:
Releases > Cycles > Suites > Test Runs:
Ensuring you use the hierarchy properly not only allows for an easier experience for your testers but also plays a large role in reporting in Insights.
Waterfall Methodology
Projects that follow a waterfall methodology have longer, less frequent releases with multiple testing phases. For example, you might have a round of unit testing, integration testing, system testing, and user acceptance testing. Users can consider these examples for this type of development methodology.
Jira Release Integration for Fix Versions
Note: Everything updated in Jira reflects in qTest in real-time
The Release Integration is configured in Project Admin>Integration Settings>Release Integration.
The Integration allows you to pull in Unreleased or Released Fix Versions.
By checking the Release Scope box, any issues being brought in as Requirements tied to that Release object will appear in the Release Scope in the Test Plan.
By Testing Stage
In Test Design, organize test cases into folders by testing stage and then by product feature to make it easy to maintain tests specific to each stage that may need to repeat in future releases. In Test Execution, use test cycles to differentiate between the testing stages that need to occur for a specific release. This approach can be useful when different teams are responsible for executing each testing phase.
Test Design Test Execution
By Feature Set
Another approach is to organize Test Design folders by product feature. Within each product, use subfolders to organize test cases for different testing phases. In Test Execution, you can separate by feature set and then by testing phase. This approach is particularly useful if different teams are responsible for creating and maintaining test cases in Test Design based on the product feature or if it is helpful to drill-down your test execution metrics by testing phase.
Test Design Test Execution
Agile Methodology
qTest Manager is ideal for Agile methodologies because it is flexible in organizing releases and sprints. In an Agile or Scrum environment, you have more frequent releases, each consisting of multiple sprints. Each sprint schedule may contain several user stories targeted for development.
Jira Release Integration for Sprints
qTest allows you to pull in your Sprints from Jira into the Test Plan. This provides your Testers with essential data in the Test Plan section. This also provides you with the Release objects for your Test Execution hierarchy, as all Release objects mirror those in Test Execution.
Note: Everything updated in Jira will be reflected in qTest in real-time
The Release Integration is configured in Project Admin>Integration Settings>Release Integration.
The Integration allows you to pull in Active, Future or Completed Sprints.
By checking the Release Scope box, any issues being brought in as Requirements tied to that Release object will appear in the Release Scope in the Test Plan.
By Sprint
Another approach is to organize Test Execution by Sprint. You can use the Release Object [the highest level object created (imported from Jira) in the Test Plan] for each sprint. This approach can be helpful for customers who have very long releases, with many sprints within the release. It can also be beneficial if there are many user stories that full testing within each sprint.
Test Design Test Execution
Complex System with Multiple Products
To track your testing for complex systems with multiple products, each having their own development and testing teams, we suggest considering the following options:
Define a Separate Project for Each Product
This approach is useful if different teams track progress for their own products and each team requires its own metrics. This may also make sense if your external ALM, like JIRA, has separate projects for each product. The one to one approach is the most streamlined. You choice simply depends on how many qTest Projects your team is comfortable managing.
Define one project for multiple products
We recommend using this option when testing products with the same release schedule. For example, the Mobile and Web products may be managed by different teams, but it is easy to track the activities of the two groups in one project if both teams are on the same release schedule. In Test Execution, you can use the cycle and suite objects to separate one product from another product. You can also use this approach if a single project management group oversees testing across these products.
Test Design Test Execution
Testing Across Multiple Browsers
When testing across multiple browsers, such as Internet Explorer and Chrome, you may want to track the differences between the browsers, but make sure you can trace back and compare how the tested browser varies from release to release. Two options are described below.
Separate Test Cases for Each Browser
One option is to organize your test cases by browser type, which means having multiple test cases for a single test. This approach is useful if the steps to execute the test vary more between browsers (e.g. the steps to execute one test case on Internet Explorer are very different from the steps to execute another test case on Chrome).
Test Design
Test run configurations for execution
For greatest efficiency, we highly encourage using the Test Run Configurations feature. This feature allows you to use a single test case (browser agnostic) and create multiple test runs, one test run for each browser. This approach is useful when the differences in test cases per browser are minimal. In Test Design, you only need to create and maintain a single test, while in Test Execution multiple test runs can be used to ensure proper testing has been done.
For more details, see Adding Test Runs with Configurations.
Customer Specific / Customized Releases
Another factor to consider when organizing your test case repository is whether you have customer-based or customized releases. Consider the balance of reusing common test cases for efficiency versus tracking functional differences. You can use two approaches:
One Project for the Product, for Multiple Customers
The first approach is to define a project per product and use separate releases per customer. This approach is useful if there are very few releases per customer and the test cases will vary minimally across the different customers.
One Project per Customer
Another approach is to use a separate project per customer. This option is especially useful if you have different release schedules for each customer, or if the application under test is innately different for each customer (e.g., different features).