I am a member on the QA team but tasked with majority of the management of the Jira instance. We have launched our product on one platform, and will be starting to develop it shortly on 2 more platforms. I am primarily concerned with just the bugs on the database for this reason. Tasks etc are used elsewhere and I only really change those upon request.

It has already been decided that we will be sticking with just the 1 project on Jira for this, for various reasons (some things out of my control etc).

We already have a "platforms" field, where we have a select box for each platform, and this has been used consistently for all bugs so far. I have all my filters, dashboards etc set up to include / filter out the platforms as I require, so all of that is ready to go.

The main thing I am thinking about right now, is our bug creation process and our bug regression process.

We regress our bugs at a semi-regular interval, and is often the fallback "if you don't have anything else to do, hit that regression list!".

What we will be having, is a process whereby when a bug is created, the creator marks the bug with the platform it was found in. This will be, for arguments sake, platform 1. This bug should show up somewhere that it now needs to be checked in platforms 2 and 3. It should be checked there and then not show up in the lists once checked (whether it effects them or not). We have multiple criteria for bugs entering our regression list at present... it depends partly on its priority, and whether it has been regressed in this build already or not.

When a bug is regressed, a field is updated with the current date to show it was regressed today. I now need all bugs to be regressed on each platform each time. But if I don't make any changes, then it will show up in all 3 regression lists until it is regressed in one platform, then it will disappear from all lists. What I need is for it to only disappear from the platform field it was regressed in...

How would you go about tackling this?

(Side note: We are using on-demand instance, so can only use plugins which work here).

  • The verb "regressed", does that mean to schedule for regression testing? The word means different things in development vs QA. When you say "on-demand instance", does that mean hosted? So you don't have the ability to add custom fields? Commented Jun 29, 2015 at 13:52
  • When I say regressed, It means that as QA, we look at the bug to see if it is still relevant. We have the bugs awaiting regression populate a table, and then when we regress them to check if they are relevant, the "last regressed" field auto updates to todays date. We do not have access to Jira fully, it is hosted by atlassian with their cloud server.
    – pingu2k4
    Commented Jun 30, 2015 at 9:30
  • Ok, do "regressed" means that a tester reviewed the steps to reproduce in order to determine if it is still possible to encounter the bug. For example, you wouldn't test for a bug in a component that was removed from the system, right? Commented Dec 2, 2022 at 3:14

3 Answers 3


The easiest way to handle this is to clone the incoming defect twice, so you have an instance of it for all three platforms. If testing against the other platforms shows it is not present, it can be closed (as "Could not duplicate", probably), otherwise it can be fixed and tested on all platforms it occurs on.


You can add custom fields and labels. Guess you just need:

  • A field/list for Found in Platform X
  • Some fields/labels to mark that it needs to processed for triage and or regression in the other platforms

Now the QA people can create filters on the fields/labels.

I think you can also add labels (check_on_platform_x, etc) to each defect on creation. Remove the labels when the actions have been taken care of. This Jira question has some ideas: https://community.atlassian.com/t5/Jira-questions/Is-there-a-way-to-automatically-add-a-Label-for-a-created-JIRA/qaq-p/244174


I'd use Sub-tasks to represent each platform. Like James Mcleod's answer this causes proliferation of JIRA issues but at least they're all linked under a single master issue and you can filter out the sub-tasks if that's the way you go. Add this to the filter:

AND Type not in (Sub-task)

and all you'' see is the main list of issues. Drill into an issue and you'll see the individual sub-tasks.

If you're not too keen on that, use a structured set of labels to represent the various states e.g. "Needs_Testing_Linux", "Needs_Testing_MacOS", "Failed_Windows", "Passed_Android" then you can use filters to identify "Needs_Testing" tasks or "Passed" tasks by adding a JQL term like:

Labels IN (Needs_Testing_Linux, Needs_Testing_MacOS, Needs_Testing_Windows)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.