Recently, TestRail engineer Jacob Scott shared his favorite TestRail Tips & Tricks. In this article, we’ll summarize some of the highlights from this webinar. For more details, you can watch the entire recording here.
- Selecting project types: 2:00
- Adding and importing test cases from a CSV file: 11:45
- Working with projects and test cases: 20:54
- Working with test runs: 29:30
- Customizing TestRail: 47:30
Selecting project types
There are three project options in TestRail, as shown below:
Selecting the project type: Choose the option that is the best fit for your team:
- Single repository – simplest to use, fewest restrictions, get started right away
- Single repository with baseline support – designed for teams that do a lot of concurrent testing for slightly different versions of a single product. You begin by building one “master” test suite and add test cases. Then, you add a baseline that you copy to create variations of the master test suite for the various platforms that you need to test.
- Multiple suites — for teams with large test suites that cover many functional areas. Some teams use multiple suites to organize tests into areas such as manual or automated, functional vs. regression, exploratory sessions, and more. Multiple suites do have some limitations. For example, when you start a test run, you can only choose one suite. So you can’t start one test run for all of the suites in the project.
Changing the project type: An administrator can change the project type. It is much easier to go from a single repository to one of the other types than to move away from one of the other types. For example, before moving away from a single repository with baseline support, you’d need to merge all of the variations into the master repository.
Granting access to the project: When creating a project, you can use the Access tab to control who has access to it. You can provide privileges in a project to user groups.
Configuring defect tracking for a project: the Defects tab allows you to specify a defect integration on a per-project basis.
Navigating to projects: By default, projects are listed in alphabetical order. But you can also use the star to mark favorite projects so that they are easier to find.
Adding and importing test cases
Setting up a CSV file: You can save a lot of time by import test cases from several formats, including a CSV file.
- Set up each test case as an individual row.
- If you’re using the “test case steps” template, then also set up each test step as an individual row. This allows you to include such details as expected results in the import, and when you execute the test, mark each step as pass or fail.
- You can also set up a section hierarchy within the CSV spreadsheet.
Mapping fields: You can easily map the test case fields in TestRail to your CSV file using the import dialog box. The important thing is to ensure that the field values in the CSV match the fields in TestRail. The import will allow you to preview the import to confirm that everything’s correct.
Managing multiple imports: if you have a lot of imports to do, you can save a lot of time by saving a CSV import configuration file and then re-using it for subsequent imports.
Working with projects and test cases
Changing the test case summary layout: by default, the Test Cases tab shows just a few columns. You can use the Columns button in the menu to add more columns. For example, if you have linked your TestRail instance to Jira for defect tracking, it can be helpful to display the References field on the Test Cases window.
Bulk editing: the bulk editing feature makes it easy to apply changes to multiple selected test cases. Simply select all of the test cases you want to update, and then choose the Edit drop-down from the menu bar. The Filter option in the menu bar is a powerful tool for selecting test cases for bulk editing.
Restructure test cases by dragging and dropping. You can grab and move an individual test case, or select the checkbox next to multiple test cases to move them as a group.
Go to the next/previous test case: When you’re viewing the details of a test case, use the left and right arrows at the top of the test case to navigate to the next/previous test case.
Copy or move test cases between test suites. It’s not necessary to export/import to copy the test cases from one project to another. Simply navigate to the destination test suite, choose the Copy or Move Test Cases button at the top of the destination test suite, and then choose the source suite. Avoid moving test cases for projects that are in use, because details such as comments and results from active test runs could be lost. Copy them instead.
Working with test runs
Tips for setting up a test run: You can add references to test runs, for example, if you’d like to link a test run to a Jira epic, or to whatever issue tracking format you prefer: stories, epics, bugs, sprints, etc. You can also assign a run to a single user right at the run level rather than the individual test level. This feature is helpful if one user will have primary responsibility for executing the test run. Use the radio buttons at the bottom to select test cases for the run: choose between all test cases, specific test cases using the standard filters, or specific test cases using the new dynamic filtering feature. Caution: if you do use dynamic filtering to choose test cases for a run, be cautious about editing the test case so that it no longer matches the filter. This would cause the test case to disappear from the run, along with any results.
Bulk enter test results: within a test run, use the checkbox to select several tests and enter results for them all at once. You can also use this feature to re-assign multiple test cases to another TestRail user for execution.
When working with a test run, use the three-pane view to quickly scan through tests in a run. Add results, mark a test as passed and move to the next one, or assign a test. You can also edit the test case directly from the test run, using the Edit button:
To close a test run, click the lock icon in the menu bar. Closing a test run cannot be undone, so make sure it’s complete before you close it. Closing a run makes sure that later changes to test cases won’t affect the test cases within the run. If you review a closed run, you know that you’re seeing the test cases as they existed during the test run.
To repeat a closed test run, use the Rerun button. Then, use the checkboxes to select the tests to be included in the new test run. For example, you could select just the failed test cases or the ones marked as untested, or all of the test cases, as shown below:
Customizing TestRail
Customizing with UI Scripts: UI Scripts allow you to add custom code using CSS, HTML, or JavaScript that can change the default appearance or behavior of TestRail. To add a UI script, open the Administration panel, click on the Customizations option, scroll to the very bottom of the window, and then click the button Add UI Script. The sample UI script for this webinar, shown below, automatically sets the “Assign To” field to blank when editing a test run:
Discover and share user-submitted UI scripts for TestRail in our GitHub repository.
Adding custom fields: TestRail supports the creation of custom fields for test cases and test results. For example, you could create a custom multi-select field with different test run result options for each project. You can also create custom fields to manage the review process on your test cases.
Creating a custom push template for defects: The default settings for a defect integration include just basic information, such as the test comments. With the ability to create a custom push template, you can static text or fields such as estimate, status, expected result, and more:
To watch the full webinar, access the on-demand recording here: TestRail Tips & Tricks
