While testing for software quality assurance in JIRA, QA engineers are supported by JQL, an efficient query system for retrieval of issues. JQL ably sifts through the hundreds, even thousands of issues related to your project and helps retrieve only those that you want to see.
Let’s look at creating some JQL queries; these can be as mundane as querying for a list of the issues resolved everyday or as crucial as listing those issues that are causing a bottleneck in the app life cycle.
Hey...who moved my ticket?
While working on my previous project, I discovered that some tickets had been declared closed on the developer end. It could be that some spec changes during the life cycle of the ticket might have caused the developers and testers to view it differently. So, I created a JQL query for such issues that had been raised by the QA team, but closed by developers, albeit unintentionally.
I used the following syntax for the query:
reporter in (Ann,Kenny,Kevin) and issuetype = Bug AND status in (Invalid, Done) AND NOT status changed by (Ann,Kenny,Kevin) and project in (Prudent)
Let’s look into the parts of the above query.
- reporter in (Ann,Kenny,Kevin) - Here, I included the names of all the QA team members.
If you have user groups in your project, they can be used in this parameter; it is much easier than writing the names of all the team members. The syntax you would need is reporter in (members of(“”)).
- issuetype = Bug - This refers to the type of issues I wanted retrieved, namely, bugs.
- status in (Invalid, Done) - I needed only those issues that had been closed.
- NOT status changed by (Ann,Kenny,Kevin) - NOT here would help me retrieve those issues that had been closed by any user other than the QA team.
- project in (Prudent) - This refers to the name of the project I was working on.
What’s on your plate?
During the course of the project, you might want to see all the tickets that have been re-opened by individual testers separately. I used the following syntax during my project to see the list of tickets re-opened by Ann:
reporter in (Ann,Kenny,Kevin) and issuetype = Bug AND status changed from "Ready for QA" to Assigned and project in (Prudent) AND status changed by Ann
- status changed from "Ready for QA" to Assigned - This will sieve out only those tickets that have been re-opened.
- status changed by Ann - You will notice that the tester has to be mentioned by name in the syntax.
Let’s get a move on with JQL
As a QA team lead, you need to ensure that the tickets keep on moving through their life cycle for quicker resolution - but what about the dormant ones? These are issues that have not seen any activity for a considerable period of time; you don’t want them cluttering up your search results. You would want to monitor them and decide if they are still relevant to the project or if, based on the latest change reports (CRs), they are redundant and need to be closed.
Let’s look at the syntax to check up on these tickets:
reporter in (Ann,Kenny,Kevin) and issuetype = Bug AND status changed BEFORE -1m and status in (Assigned) and project in (Prudent)
- status changed BEFORE -1m - This will help sift out the issues that have not seen any activity in the last 30 days.
Kudos to the team
As a QA team lead, you would want to monitor the issues resolved regularly, maybe every week or, if you run a tight ship, every day. Besides, it gives you and your team a sense of achievement, seeing the number of issues you resolved that day. After all, a small step for the team...you know the rest!
The syntax would be something like this:
creator in (Ann,Kenny,Kevin)
AND updated > -1d AND status changed to "Fixed on QA" AND status = Resolved
- creator in (Ann,Kenny,Kevin) - The QA team members are mentioned by name as the creators of the issues.
- updated > -1d - The issues resolved on that day will be displayed.
The above syntax can be used in run time by creating a filter. Just remember, the syntax updated >-1d can be used from Tuesday onward till Friday or Saturday, whichever is the last day of your work week. If you want to run this filter on Monday, you will have to use the syntax updated > -2nd or -3d, depending on the last work day of the previous week.
The efficiency of JQL lies in that the queries can be based on a wide range of system and custom fields and values. They can be saved for future use as filters and the use of functions in queries ensures that the latest results are returned.
If you want to learn more about JQL, refer to
https://confluence.atlassian.com/jira/advanced-searching-179442050.htm
So, go ahead and use the power of JQL; may the force be with you!
