Workflow example for test cases in Atlassian Jira
On the market (and in OpenSource) there are enough specialized systems for testing, a good overview, for example, here . There are also experienced testing specialists who prefer the good old Excel. In principle, the choice of a working tool is the prerogative of a professional, which is more convenient, and I work in that. But what if you make the tool yourself - based on the software used by the developers?
Under the cut - how can this be done in Jira.
So, we have a licensed Jira (for Open Source lovers, it’s quite possible to negotiate with Atlassian or use the Developer's version from the SDK). Naturally, QA engineers have access, they also need to post bugs. Why not start a project for test scenarios and do no worse than in TestRail?
The scripts are described in the Excel table. Each step of the test script is on a separate line. Accordingly, the columns are the instruction, a positive result, the priority of the bug, the tested functionality, the number of the testing phase, the system (for example, the iPhone version), and what you want, for example, of the component.
It is also advisable to have a scripting plugin in Jira to automatically carry out tickets step by step depending on the events. I personally prefer this one , but you probably already have everything, you just need to ask the programmers.
Well, the admin rights to edit the project - you know better how to do it, so we will not harness the duty administrator on trifles.
In principle, we need a system that will store scripts, all comments, it allows us to present everything in a table form, and most importantly, we can go through the script step with two clicks of the mouse. Well, since we are in Jira - to automatically create bugs with the correct fields.
Create a new project Test Scenarios. Each script will have a separate ticket. Each step of the script is a subtask.
1. We look at the table with the scripts and create all the Custom Fields that we need. If programmers already have them - it’s even easier, we write down their names, they will be useful to us when importing.
2. We form the Summary and Description columns in the table.
The summary for the steps should look something like this: Step Description - Result
Description is a figment of your imagination. But it’s very good to know the Jira markup and actively use tables, user links, headers, etc., etc. Nothing to screen, Jira eats and does not choke.
Example markup: = “h1. "& A2 &" h2. "& B2 &" \\ || Col1 || Col2 || " & CHAR (10) & "|" & C2 & "|" & D2 & "|"
Line break - CHAR (10), hard line break in Jira (needed before tables) - \\
3. For each line, enter the ticket and parent numbers. With the ticket number, everything is simple - end-to-end numbering starting from 1 (in principle, there can be any unique identifier, it does not matter). The parent is empty for the script, and the step has the script number. The formula in Excel is trivial.
4. If you enter separate names for tickets in Jira instead of the standard Task and Sub task, you will need a column for the name of the type of ticket.
5. Save everything to CSV in UTF-8 format. We import through the administrator menu (look for Import in the search box). The main thing is to map your speakers to the correct fields.
You also need to remember that Jira cannot import more than 250 lines at a time, so it’s possible that you have to split the table into several.
So, we got dozens of scenarios, in each of which there are many steps, subtasks. What is good for us?
We open the script. All steps are at the bottom of the script. All you need to do is click on ... and select the transition from the subtask to the Passed or Failed state. Two clicks for success is not bad.
Here we need a plugin. I describe how I do it in JMWE.
In the Workflow for the Sub task, find the Transition from Open to Failed and create a Post Function to create a new bug. We copy the necessary fields, the last comment and attachments. We execute on behalf of the current user. Save.
Add Transition Screen. It can, in principle, be empty - if you have enough comment. Or contain other fields.
Now when you transfer the Sub task from Open to Failed - a window pops up where you enter the description of the bug, attach a screenshot and fill in other fields to your liking - and developers get a bug that attaches to a specific step of the script. Convenient - you can immediately see who made the bug, how, where and when. No copy paste.
And one more important advantage - in the sub-task there is a full history of who and when tested, what comments he made, what bugs were found. All in one.
One option is that as soon as the bug is fixed and available for testing, the programmer puts the fallen test into the Open state and QA can continue testing. If regression is suspected, we find the appropriate scripts and subtasks and use Bulk Update to translate from Done to Open.
It is very important for the programmer to know the specific version of the build that crashed (or broke). There may be several options. For example, create a separate ticket of the Epic type which lists the versions of the tested components and add all test scripts to this Epic. The plugin comes off in Epic, picks up the version and adds it to the bug. We'll have to torment ourselves with the script once, but then there will be happiness.
The version of iron. It can be thrust into the properties of the user Jira. For example, Vanya Pupkin has Android 9.0.1 and an Asus Zen 12 phone, and Lena Ignatova has a pink Iphone X and iOS 1.4.3. The script will read the user’s fields and automatically insert it into the bug.
Specialized systems are good, especially for testers, but it can be inconvenient for programmers. Excel is also good if there is only one tester. Jira is a developer tool, but it’s quite possible to configure it to be convenient for a QA specialist. And we get the visibility and speed of testing from TestRail, the ability to table presentation of Excel, as well as full integration with development projects.
Under the cut - how can this be done in Jira.
So, we have a licensed Jira (for Open Source lovers, it’s quite possible to negotiate with Atlassian or use the Developer's version from the SDK). Naturally, QA engineers have access, they also need to post bugs. Why not start a project for test scenarios and do no worse than in TestRail?
Introductory conditions
The scripts are described in the Excel table. Each step of the test script is on a separate line. Accordingly, the columns are the instruction, a positive result, the priority of the bug, the tested functionality, the number of the testing phase, the system (for example, the iPhone version), and what you want, for example, of the component.
It is also advisable to have a scripting plugin in Jira to automatically carry out tickets step by step depending on the events. I personally prefer this one , but you probably already have everything, you just need to ask the programmers.
Well, the admin rights to edit the project - you know better how to do it, so we will not harness the duty administrator on trifles.
What do we want
In principle, we need a system that will store scripts, all comments, it allows us to present everything in a table form, and most importantly, we can go through the script step with two clicks of the mouse. Well, since we are in Jira - to automatically create bugs with the correct fields.
Go
Create a new project Test Scenarios. Each script will have a separate ticket. Each step of the script is a subtask.
1. We look at the table with the scripts and create all the Custom Fields that we need. If programmers already have them - it’s even easier, we write down their names, they will be useful to us when importing.
How not to do Custom Fields in Jira
As part of personal hygiene, I do not recommend mixing small with liquid and not using global Custom Fields. Each field must belong to a specific configuration. It’s like a global namespace in programming - you shouldn’t overwhelm it with unnecessary types and variables. And yes, if Custom Field with the same name already exists, think three times whether you need a crap if you name another field exactly the same. In principle, this is surmountable, but cactus is not better.
2. We form the Summary and Description columns in the table.
The summary for the steps should look something like this: Step Description - Result
Description is a figment of your imagination. But it’s very good to know the Jira markup and actively use tables, user links, headers, etc., etc. Nothing to screen, Jira eats and does not choke.
Example markup: = “h1. "& A2 &" h2. "& B2 &" \\ || Col1 || Col2 || " & CHAR (10) & "|" & C2 & "|" & D2 & "|"
Line break - CHAR (10), hard line break in Jira (needed before tables) - \\
3. For each line, enter the ticket and parent numbers. With the ticket number, everything is simple - end-to-end numbering starting from 1 (in principle, there can be any unique identifier, it does not matter). The parent is empty for the script, and the step has the script number. The formula in Excel is trivial.
4. If you enter separate names for tickets in Jira instead of the standard Task and Sub task, you will need a column for the name of the type of ticket.
5. Save everything to CSV in UTF-8 format. We import through the administrator menu (look for Import in the search box). The main thing is to map your speakers to the correct fields.
You also need to remember that Jira cannot import more than 250 lines at a time, so it’s possible that you have to split the table into several.
So, we got dozens of scenarios, in each of which there are many steps, subtasks. What is good for us?
We open the script. All steps are at the bottom of the script. All you need to do is click on ... and select the transition from the subtask to the Passed or Failed state. Two clicks for success is not bad.
Automatic bug detection
Here we need a plugin. I describe how I do it in JMWE.
In the Workflow for the Sub task, find the Transition from Open to Failed and create a Post Function to create a new bug. We copy the necessary fields, the last comment and attachments. We execute on behalf of the current user. Save.
Add Transition Screen. It can, in principle, be empty - if you have enough comment. Or contain other fields.
Now when you transfer the Sub task from Open to Failed - a window pops up where you enter the description of the bug, attach a screenshot and fill in other fields to your liking - and developers get a bug that attaches to a specific step of the script. Convenient - you can immediately see who made the bug, how, where and when. No copy paste.
And one more important advantage - in the sub-task there is a full history of who and when tested, what comments he made, what bugs were found. All in one.
Bug fix
One option is that as soon as the bug is fixed and available for testing, the programmer puts the fallen test into the Open state and QA can continue testing. If regression is suspected, we find the appropriate scripts and subtasks and use Bulk Update to translate from Done to Open.
Versioning
It is very important for the programmer to know the specific version of the build that crashed (or broke). There may be several options. For example, create a separate ticket of the Epic type which lists the versions of the tested components and add all test scripts to this Epic. The plugin comes off in Epic, picks up the version and adds it to the bug. We'll have to torment ourselves with the script once, but then there will be happiness.
The version of iron. It can be thrust into the properties of the user Jira. For example, Vanya Pupkin has Android 9.0.1 and an Asus Zen 12 phone, and Lena Ignatova has a pink Iphone X and iOS 1.4.3. The script will read the user’s fields and automatically insert it into the bug.
findings
Specialized systems are good, especially for testers, but it can be inconvenient for programmers. Excel is also good if there is only one tester. Jira is a developer tool, but it’s quite possible to configure it to be convenient for a QA specialist. And we get the visibility and speed of testing from TestRail, the ability to table presentation of Excel, as well as full integration with development projects.
All Articles