Organization of UAT testing for business users in Jira
Input data. Our product is almost ready for shipment, it remains to pass acceptance testing. The test plan is ready and presented in the form of an Excel spreadsheet. Future users will be tested, that is, people far from QA and IT.
Task. Make it convenient for everyone. Users in theory should read the description, pass the test and click the “Pass” button. Programmers must quickly respond to a fallen test and post a fix. Well, graphs and statistics by itself, so that the manager understands where we are.
Disclaimer. Of course, QA in the company has its own professional testing tools, specifications, test cases, etc., etc. But ordinary users only need to see what they need to pass the test. Forcing them to learn Testlink, for example, is too much.
Why jira Because tickets (I will use this term as an issue below) are easily linked to each other. And in reserve, a large organization probably has several inactive accounts (for example, from retired employees or bought in reserve), which can be allocated for a couple of weeks for tests. All tests will be in one place, nothing will have to be deployed additionally.
')
So the solution itself. We are launching a separate project for acceptance testing. We import test cases in it in the form of tickets. We draw beautiful dashboards for users and management. We make automatic creation of bugs when you click on the Failed button in the ticket. Profit
The project will suit both the newfangled next-gen, and the classic Software or even Service Desk. With the “next generation” everything is simple, it is configured by dragging and dropping with the mouse for 15 minutes. But there is one thing - you cannot modify the Workflow, accordingly it is impossible to change the Transitions and we lose many automation options, not to mention showing the Transition screen when a bug is detected.
Therefore, we choose a classic project.
Everything is simple here. The three states are Open, Passed, and Failed. Transitions from any state to Passed and Failed. If desired (for statistics), the Reopened state, where tests get after fixing a bug or suspecting regression. If Reopened is not needed, we get to Open accordingly, otherwise Open will be only for new test cases.
Fasten a simple borderless form to the Failed transition so that the user can enter a comment and attach a screenshot. On the post-function (post function) we hang the creation of a ticket in the same or neighboring project, where we copy the last comment and link like causes.
Choose a workflow for the bug to your liking. But it is important that either the programmer or the script, as a result of laying out the corrected version, translate the linked tickets to the Reopened (or Opened) state. Then they automatically fall back into the general heap of tests.
There is no need to fence anything, Jira can do everything out of the box. The main thing is to prepare the right CSV. Namely - each ticket is a line, the title of the fields is desirable in the header (so as not to get confused). Well, if you wanted to group test cases by epic - links to pre-prepared epic tickets.
Custom fields are prepared as usual. Personally, so that I do not swell the REST interface for creating a ticket, I do everything according to the full program - I create a field map, delete everything that does not apply to a specific ticket, add new fields only in the necessary configuration. Yes, it’s steep, but it’s immediately clear which field belongs to which project and there is no chaos. In addition, many people like to name fields the same way, and then guess why this or that script does not work. If done wisely, the Where is my field function helps well - it shows in detail where you messed up and provides links to configuration pages - very convenient.
However, we were distracted. If you plan to use 2 dimensional tables in dashboards, I highly recommend that you do not list all the rows in rows, namely Select single. Filling the list is easy - in Excel, do Pivot column by column and type values ​​in the Jira custom field.
About the import process itself. Everything is simple here. In the middle column, select the field name in Jira, in the right column, whether the value will be converted upon import (Mapping) or simply copied as is. For Single Selection, I recommend leaving the Mapping value pure to make sure everything is in order. For everything else, you can not "map."
For example, we have 4 fields - Test Description, Prerequisites, Steps and Planned Result. We make the Description column and summarize the fields using the & operator or if you like Concatenate so much. For line break we use CHAR (10). For fields unnecessary to the user, we insert the table. Headings and you know it yourself - h1. For unconditional line break (needed in front of the table), put \\. Everything, the test description is ready, read and execute. Yes, for all markup to fall into Jira, you need to disable mapping for Value for this field (it is already disabled, so just do not enable it).
Linking to another ticket is simple. The column name is Link 'blocks', the content is the ticket key. When mapping, select the correct link type.
Well, the last thing worth mentioning is that the maximum number of tickets to import into Jira cannot exceed 250. If more, stupidly copy the table line by line to sheets and save it in separate CSV files. I personally call them 1-250.csv, 251-500.csv and so on so as not to get confused.
As in any other dashboard building business, it is best to prepare filters in advance. Especially if you have multiphase testing. Then, to prepare a dashboard of another phase, it will be enough to copy the dashboard and hang other filters.
I personally like these gadgets:
Users can give a link to the dashboard and say “get tickets from the Status vs Component table” from the Open and Reopen columns. Choose a ticket, read the description, execute and click Passed or Failed. If Failed, drive a comment into the window, preferably with a picture (Alt-PrintScreen, Shift + Ins). Everything.
Nothing unusual, we do as always. Unless I would recommend creating a separate scheme and giving rights to specific users for specific operations, not including them in groups. Then they will not get into other projects, and it will be easy to clean them up (just changing the scheme to the standard one). And yes, after testing is completed, we make users inactive by returning licenses to the system.
That's all. In general, setting up a project for UAT testing will require four hours, and deploying an existing project to other tests will take about 15 minutes. And you do not need to install anything.
Task. Make it convenient for everyone. Users in theory should read the description, pass the test and click the “Pass” button. Programmers must quickly respond to a fallen test and post a fix. Well, graphs and statistics by itself, so that the manager understands where we are.
Disclaimer. Of course, QA in the company has its own professional testing tools, specifications, test cases, etc., etc. But ordinary users only need to see what they need to pass the test. Forcing them to learn Testlink, for example, is too much.
Why jira Because tickets (I will use this term as an issue below) are easily linked to each other. And in reserve, a large organization probably has several inactive accounts (for example, from retired employees or bought in reserve), which can be allocated for a couple of weeks for tests. All tests will be in one place, nothing will have to be deployed additionally.
')
So the solution itself. We are launching a separate project for acceptance testing. We import test cases in it in the form of tickets. We draw beautiful dashboards for users and management. We make automatic creation of bugs when you click on the Failed button in the ticket. Profit
Implementation details
The project will suit both the newfangled next-gen, and the classic Software or even Service Desk. With the “next generation” everything is simple, it is configured by dragging and dropping with the mouse for 15 minutes. But there is one thing - you cannot modify the Workflow, accordingly it is impossible to change the Transitions and we lose many automation options, not to mention showing the Transition screen when a bug is detected.
Therefore, we choose a classic project.
Workflow
Everything is simple here. The three states are Open, Passed, and Failed. Transitions from any state to Passed and Failed. If desired (for statistics), the Reopened state, where tests get after fixing a bug or suspecting regression. If Reopened is not needed, we get to Open accordingly, otherwise Open will be only for new test cases.
Fasten a simple borderless form to the Failed transition so that the user can enter a comment and attach a screenshot. On the post-function (post function) we hang the creation of a ticket in the same or neighboring project, where we copy the last comment and link like causes.
minute of advertising
In no way being connected with the authors of the plugin I strongly recommend JMWE for automation tasks. An exceptionally flexible tool, you can write any script that anyone understands, Monsieur, who understands perversions. It works without problems, there is a testing and logging mode
Choose a workflow for the bug to your liking. But it is important that either the programmer or the script, as a result of laying out the corrected version, translate the linked tickets to the Reopened (or Opened) state. Then they automatically fall back into the general heap of tests.
Import test cases
There is no need to fence anything, Jira can do everything out of the box. The main thing is to prepare the right CSV. Namely - each ticket is a line, the title of the fields is desirable in the header (so as not to get confused). Well, if you wanted to group test cases by epic - links to pre-prepared epic tickets.
Custom fields are prepared as usual. Personally, so that I do not swell the REST interface for creating a ticket, I do everything according to the full program - I create a field map, delete everything that does not apply to a specific ticket, add new fields only in the necessary configuration. Yes, it’s steep, but it’s immediately clear which field belongs to which project and there is no chaos. In addition, many people like to name fields the same way, and then guess why this or that script does not work. If done wisely, the Where is my field function helps well - it shows in detail where you messed up and provides links to configuration pages - very convenient.
However, we were distracted. If you plan to use 2 dimensional tables in dashboards, I highly recommend that you do not list all the rows in rows, namely Select single. Filling the list is easy - in Excel, do Pivot column by column and type values ​​in the Jira custom field.
About the import process itself. Everything is simple here. In the middle column, select the field name in Jira, in the right column, whether the value will be converted upon import (Mapping) or simply copied as is. For Single Selection, I recommend leaving the Mapping value pure to make sure everything is in order. For everything else, you can not "map."
Life hack
Remember that we are not ordinary users, or rather, simple users who have never worked in Jira. Therefore, the fewer fields, the better. Ideally, the entire description of the test case can be wrapped in Description, since the pseudo-layout is fully supported.For example, we have 4 fields - Test Description, Prerequisites, Steps and Planned Result. We make the Description column and summarize the fields using the & operator or if you like Concatenate so much. For line break we use CHAR (10). For fields unnecessary to the user, we insert the table. Headings and you know it yourself - h1. For unconditional line break (needed in front of the table), put \\. Everything, the test description is ready, read and execute. Yes, for all markup to fall into Jira, you need to disable mapping for Value for this field (it is already disabled, so just do not enable it).
Linking to another ticket is simple. The column name is Link 'blocks', the content is the ticket key. When mapping, select the correct link type.
Well, the last thing worth mentioning is that the maximum number of tickets to import into Jira cannot exceed 250. If more, stupidly copy the table line by line to sheets and save it in separate CSV files. I personally call them 1-250.csv, 251-500.csv and so on so as not to get confused.
Dashboard
As in any other dashboard building business, it is best to prepare filters in advance. Especially if you have multiphase testing. Then, to prepare a dashboard of another phase, it will be enough to copy the dashboard and hang other filters.
I personally like these gadgets:
- Two dimensional
- Status vs Component - Filter counts
- few people guess, but there you can hang absolutely any JQL, for example, the total number of bugs for the component. - Issue statistics
- just the statuses of tickets in percent. - Activity stream
- for this project
Users can give a link to the dashboard and say “get tickets from the Status vs Component table” from the Open and Reopen columns. Choose a ticket, read the description, execute and click Passed or Failed. If Failed, drive a comment into the window, preferably with a picture (Alt-PrintScreen, Shift + Ins). Everything.
Adding Users
Nothing unusual, we do as always. Unless I would recommend creating a separate scheme and giving rights to specific users for specific operations, not including them in groups. Then they will not get into other projects, and it will be easy to clean them up (just changing the scheme to the standard one). And yes, after testing is completed, we make users inactive by returning licenses to the system.
That's all. In general, setting up a project for UAT testing will require four hours, and deploying an existing project to other tests will take about 15 minutes. And you do not need to install anything.
Source: https://habr.com/ru/post/461757/
All Articles