Houston, we are go for launch! Just a few small steps for us, but one huge step for the testing world – how to prepare test results for JIRA and then send them.
If you’ve read the previous part of the article, you’ve probably noticed that you’re stuck at this point. Yes, you do have a JSON report on test results ready, but it is still not JIRA-ready. Well, this is where your skills are developer will be tested.
You will notice that the JIRA-ready JSON scheme features details such as test execution and test plan JIRA keys. This data will mostly be static, so it can be either hardcoded then manually updated afterward or we can make it dynamic by getting the exact test execution and test plan data via JIRA API and storing them into variables. It, once again, depends on your personal preferences.
Once we’ve entered all the necessary and optional data and created a functional, JIRA-ready JSON scheme, all we need now is a for-loop which will iterate over our initial JSON report, extract the data (e.g. status and comment) and then push the data in a “tests” array in our JSON scheme.
All of this we will save into a new, JIRA-ready JSON file. Congratulations, you’re finally set to go!
The final countdown
And here it is, the final step in our JIRA Automation workflow! It’s time to tell JIRA and XRay to change the status of the tests in the test execution task. How do we do it?
As we’ve already mentioned, we do it via API request. If you take a look at the JIRA and/or XRay documentation, you will notice that they’ve exposed their endpoints for viewing, creating and modifying almost anything in the JIRA app. We will use these endpoints to create a curl command which will send the results, along with the authorization data, to JIRA.
After you’ve, presumably, modified JIRA test tasks (getting response with status code 200 should be enough by itself, but we’ll double check), it’s time to visit your JIRA test execution and verify all test tasks have either “PASS” or “FAIL” status. If that’s not the case, then you’ve probably missed something in one of your steps. Make sure you double check everything every step of the way because even the slightest typo or mistake in your JSON file is bound to break the whole process and leave you without any kind of change to JIRA tasks.
If the results are alright, congratulations, you’ve just completed the JIRA automation workflow for the first time! Hopefully, it was worth it.
The final step, an optional one, is to do some clean-up for maintenance purposes. Basically, our final step is to remove the initial JSON report file from the hard drive. One could remove the JIRA-ready one as well, but we’ve decided to always keep the most recent one, for auditing purposes.
A beautiful Bash script
Of course, JIRA automation would not be automation if you were to perform the whole workflow by hand. That’s why we decided to encapsulate all steps of the workflow in one big bad Bash script.
We start the Bash script after we’ve created our test tasks (from test plan to test execution).
It does the following:
- Runs Cypress tests in headed Chrome
- Executes curl command which sends the file via API request to JIRA
- Deletes unnecessary leftover files
One more step could also be added to the workflow, but we didn’t think of it as really necessary at the moment. User could also use curl command to get the test execution files and verify, by its content, that tests we actually updated. This would eliminate the need to go to JIRA manually and check test status, but we felt that a good old “believe your own eyes” approach would be better. However, it does not mean that you should do the same.
As we’ve already mentioned, the process of JIRA automation is not a necessity. However, automation testing is not a necessity at all. But we still do it. Why? To increase efficiency and to leave the unnecessary worries to some different medium.
By automating JIRA behavior, we’ve realized that we no longer have to go to JIRA physically and update or create tasks. This can be done by the machines. We did make an effort to verify end results of our workflow manually, but that can be avoided completely, as aforementioned.
We’ve also mentioned that this may not be the best or even the fastest way to do JIRA automation – we settled for the “working version”. Nevertheless, it doesn’t mean that we’re completely content and that this is THE solution. On the contrary, this is just the beginning of something new, an old concept in new clothes.
The idea is to go for the full automation of the manual processes in a given environment. If one can modify test tasks, then why not modify everything else in JIRA as well? This would mean that we can automate task creation, bug creation, status updated, etc. without having to do anything but our jobs, and that is to develop and assure the highest standards of quality in the product. To us, it sounds like the maximum efficiency formula.