Introduction
In many projects that I worked with, people did not customize TestRail for themselves and managed with standard settings. Therefore, in this article I will try to describe an example of individual settings that can help you increase the efficiency of your work. For example, let's take a mobile application development project.
Small disclaimer. This article does not describe the basic functionality of TestRail (there are many guides for this) and selling expressions colorfully describing why you need to choose this particular vendor to create a repository with tests.
Plan-justification (what will be implemented)
-
General requirements
-
The case should be able to pass absolutely anyone
-
Cases should remain relevant for as long as possible
-
Cases should cover the functionality of the mobile application as carefully as possible to the extent that this does not contradict the first two points.
-
-
Separation into TestCase and TestScenario
-
Fast formation of TestRun of various types
-
Smoke
-
regress
-
Impact testing, etc.
-
-
Case support optimization
-
Rejection of "dead" hard-coded screenshots and transition to "movable data"
-
Requirements
You will need administrator access to edit fields
Selecting a project type
There are three project types to choose from:
We will choose the default type. All cases will be available in it at the same time. We will use smart filtering and dynamically manage all cases at once.
Adding fields to view the list of test cases
Let's add a field to display priority test cases:
You can also add other fields.
Setting fields and tags of a test case
Opening the settings menu:
We need these fields:
βSummaryβ field (test case header)
This field already exists, we only systematize its use. We will divide cases into TestCase and TestScenario. For better readability of a large list of cases, it is better to agree in advance on the rules for writing a summary.
Test Scenario:
Example: TestScenario - Mobile Application Main Use Case
testcase:
Example: MainScreen - Authorization section - Login entry
In total, we see in the summary of the case a classic understanding: βwhat, where, whenβ. We also visually separate high-level test scripts and low-level test cases in the most suitable form for automation.
Tag "StartScreen" (the screen from which the TestScenario starts, also many test cases can touch neighboring screens)
For what it may be needed: we will remove the typical steps from the text of the cases that lead the user to the screen of the current test case. (typical steps for creating a specific test situation) All typical steps for all test cases will be written in one file. I will write about it in more detail separately.
Create a new field:
Fill in the components of the new field:
In this case, we are creating a select field from a list of values. Enter the values ββfor this field:
Note that the id values ββdo not start at one and are not consecutive. Why is this done? The fact is that if we have recorded test cases with the entered id,
and after that we need to create a third screen between the two existing ones,
then we will have to rewrite the id, and since the tags of the existing text cases are already attached to it, they are simply deleted. It will be very unpleasant.
Tag "Screen" (the name of the screen that affects the TestCase)
What you may need: one of the anchors for impact testing. For example, the developers have made a cool new feature. We need to test it, but for this we need to understand what exactly this feature could affect. By default, we can start from the paradigm that different screens (Activities) of the application have different classes and therefore constitute different components of the application. Of course, in this case, an individual approach is needed.
Example: home_screen, MapScreen, PayScreen, etc.
MovableData field (link to proxy database with mutable test data)
Next, we will try to solve the problem of maintaining the relevance of data in test cases:
-
Links to actual layouts (this is much better than taking dead screenshots)
-
Typical steps to the test case screen
-
SQL queries
-
Links to external data and other data
Instead of writing test data inside each test case, we will create one external file, and on all test cases we will make a link to it. When updating this data, we will not have to go through all the test cases and change them, but it will be possible to change this data in only one place. If someone unprepared opens a test case, he will see in the body of the test case a link to a file and a hint that you need to go to it for test data.
We will pack all this data into one external file, which will be available to everyone on the project. For example, you can use Google Sheet or Excel and set up a search inside the file. Why these particular vendors? The fact is that we start from the paradigm that any person in the team should be able to open and pass the test case without the need to install any tools first.
For Google Sheets SQL queries can be used. Example:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")For Excel You can set up convenient instant search macros. (filtering) Example .
Actually, the idea is not new and is described in the first book of the tester βTesting dot comβ. (author Savin Roman) We just integrate the methods proposed by Roman Savin into TestRail. To do this, create a field with a link to the created file:
fill in the default value of the link so that in each new test case there is already a link:
If the location of the external file changes (we provide for any force majeure), then you can conveniently change one or more fields in all test cases at once:
Field βDescriptionsβ (description or idea of ββthe test case, typical instructions)
What you may need: In this text field, we will place a brief description of the test case and typical instructions.
Example: All test data (actual layouts, use of tools, and other data) from this test case are marked with {...} links and are located in the MovableData. Link to MovableData in the corresponding field at the top.
"Component" tag (mobile application component)
What you may need: for impact testing. If a mobile application can be divided into components (which affect each other as little as possible), then changes in one component will be enough (with some risks) to check within the same component, and there will be less reason to conduct general regressions of everything and everything. If there is information that one component can affect another, then an impact testing matrix is ββcompiled.
Example components: GooglePay, Order, Users, Map, Authorization, etc.
Tag "TAG" (Other tags for filtering)
Tagging a test case with labels for arbitrary filtering.
Very useful for:
-
quick compilation of TestRun for various typical tasks: smoke, regression, etc.
-
whether the tests will be automated or already automated
-
any other tags
Example: Smoke, Automated, WhiteLabel, ForDelete, etc.
Setting the display order of fields in the test case
We have created a lot of new fields, it's time to arrange them in a convenient order:
Creating TestRun
Now we will create a new test run with relevant cases for smoke testing in three clicks:
Other useful tips
-
If there are several projects in TestRail, then do not forget to create new fields only for your project, otherwise colleagues from neighboring teams will be very surprised at the appearance of new unusual fields. Local fainting is possible.
2. Cases with a large number of fields are easier to copy from a similar type group than to create new ones:
3. Accounts can be shared. For example: one administrator, several user.
Conclusion
The above examples have been implemented on several projects and have shown their effectiveness. I hope they will help improve your understanding of this tool and help you create efficient and convenient "dough storage". I would be very grateful if you describe your experience of using TestRail and useful tips in the comments.
Links:
Book:
Thank you very much for your attention!
Source: habr.com