Delivering a quality software product can be very challenging, especially when it comes to large scale projects that require a great level of measurement. We need to have a stable testing process with a good set of test cases and great tool support. Unfortunately, many organizations lack the tools to manage their test cases. Today we’re going to take a look at the software tool called JIRA. Although it is not intended to work as a test case management tool, it can definitely be a starting point that can add value to the testing process.
Table of Contents
What is JIRA?
JIRA is originally designed to be an issue tracking software developed by Atlassian. It is the most popular software development tool at the moment, especially for agile oriented teams. The basic use of this tool is to track user/technical stories, create bugs or change requests on SCRUM and Kanban boards and trace their workflow trough previously defined steps. It appears that although JIRA is not focused on managing test cases, many organizations are actually using it for their test management process.
Why using JIRA?
As a first choice to work with when it comes to Agile organization, JIRA has a variety of functionalities. It ranges from capturing requirements, creating epics, improvements, technical details, bugs, etc. All these types of tickets are presented on a board where you can easily track their progress. Also, you can create workflows to follow and track your business process. By using JIRA, many organizations will have a centralized source of information. When there is a need for documentation for a release, JIRA can provide some in-depth info about any features that we’ve worked on, technical stories for improved testing or development process, change requests from customers, previously reported bugs found by the testers, etc.
When you have defined some stories, then you can create the sprint that will include those stories that should be worked on in the next couple of weeks. After the sprint is finished we can export the sprint results in a so-called Burndown chart where we can see our actual progress compared to the expected progress. With JIRA we can also estimate our stories by entering some story points. Story points are estimates of effort for a specific story. It can be 1,2,3,5,8,13,20,40 etc. Depending on the complexity of the story we add a higher story point.
Notifications to our email can be integrated with JIRA. When we do some changes in a ticket that we are assigned or we are set as watchers then an email notification is sent to us reminding us that someone changed the information of the ticket. It can also integrate within our continuous integration process, we can create branches from the story itself to link all our development, testing work with the ticket immediately.
Third-party tools like Slack messaging platform or Zephyr test case management tool can be integrated with JIRA so that we can have an overall controlled project structure.
Test Case Management
As I said, JIRA is not intended to be used as a test case management tool solely but because of its power many teams are using it for their testing process and it can easily become a habit to write a test case in JIRA in a task or a tech story.
Here are several tips to create a test case in JIRA:
- Create a Test Case issue
- Define all the steps required to pass the test case
- Define the configuration needed for executing the tests
- Create a sub-task from that Test Case which will be labeled as test execution
- Enter the results from the execution, the affected version and the assignee of that task
This can be challenging when it comes to re-running already executed tests. We already have put the test evidence as a result of our initial run but when we want to execute them again on the same version then we must create another test execution task or enter the results from the execution in the same subtask. The first option will be a bit of overhead especially when we want to re-run our tests multiple times. The second option can create confusion about our number of runs on the affected version and it will not be a best practice.
However, you can tweak it a little bit by creating a User Story for the main functionality, then creating a task for testing. Under that task, you can create sub-tasks for the testing environment configuration, test case design, test execution, etc. That is one way to do that and usually, that is the preferred way for those who do not use any test case management tool and are relying on JIRA for all of their testing/development activities.
Pros and Cons
The advantages of using JIRA for your test case management process are:
- Smooth workflows for testers and developers
- Creating test cases as custom tasks
- Nice reporting at hand
- Great tool support
The disadvantages are:
- Not a testing specific oriented tool
- Duplication when re-running tests
- Limitations around test suites executions, environment configuration, versioning, etc.
- No traceability report from the test coverage
Because of its limitations, JIRA is not well suited for test case management and centralized testing efforts, although it can be very easy to tweak it and apply it to your testing process by following the steps mentioned before. You can use some other add-ons tools like Zephyr. Zephyr is a testing tool that is integrated inside JIRA. With Zephyr, you can create test issues, executed them, track their workflow, and export a report from their execution. It’s UI is similar to JIRA, which can be deployed on server or cloud and it has an API that can be used to integrate it into your CI tools.
The Bottom Line
I can’t say that you must use JIRA only or some add-ons or any other integration tool. That depends mostly on the size of your team and the organization’s goals. If you need a test case management tool that you heavily rely on in order to drive your testing efforts, then you definitely need a third-party test case management tool, preferably integrated with JIRA. But if the organization is fine by using JIRA as a test case management tool where some predefined methods are agreed to be followed when creating a test case then it should not cause any problems among the testing teams as long as they comprehend the rules set by the company.
Share this post