Workflow status vs environments

[Kamila Guzman]

Hi All,

I'm wondering how to approach this situation:

I have a new story that is currently in development. In JIRA I have the status set to IN PROGRESS until Dev and Unit Testing is complete. I then need to move the story through QA/BETA/Prod environments. I wonder what status should be best for the story for each environment. Do I simply have a separate status for "In QA Testing", "In BETA Testing", etc.?  Or is there a more elegant way to do this? The issue is that if I have multiple QA Statuses in each environment, the corresponding JIRA board gets crowded but the raw data is more accurate for management readouts. Thoughts?

Does this make sense? 

In Summary: Is the best way to track QA progress in each of the environment to setup a set of status for each environment or is there a more sophisticated way to leverage Jira functionality to accomplish the same results (e.g., I considered trying to use a combination of the environment attribute and the status to arrive at a detailed break down but this seems to make reporting and dashboarding more complex).  

Thank you 

[Radoslaw Cichocki _Deviniti_]

Hi @Kamila Guzman,

Best-case scenario is that you have a test management app like RTM or TestFLO, and use a separate issue type (test case / test case execution) for tracking test progress.

Then your story could just have a workflow status called "Testing", and the underlying test case executions, separate for each environment ("Environment" field) , would have their own workflows and their own statuses.

It's not the best approach to build your whole QA workflow into your requirement workflow. It's just not where it belongs. Better keep them separate. It also helps reporting a lot, especially if you also use test plans and test repositories organize your tests.

Regards,
Radek Cichocki

[Stephen Wright _Elabor8_]

Hi @Kamila Guzman 

Personally, I wouldn't have separate Statuses unless it's a last resort. The main reason for this is exactly as you've identified - you can end up with a very long, and complex, Workflow.

I'd suggest considering:

• Testing App: Utilising an App such as Zephyr Scale or Xray Test Management where all this functionality is inbuilt
• Issue Type: Similarly, you could have an Issue Type for Tests - either linked to an Issue, or as the Sub-task of it. That way each Test is tracked individually, with a specific resolution date as the end-point.
• Environment Field: If you are going to use an Environment field, unless you need the exact Environment it's in I'd consider creating a Select List field just listing UAT, QA, BETA, etc - to make it simpler. 
  • A further enhancement could be to have a field tracking last Environment change with a date, which is populated by Automation - if you want to see how long something has been in a particular environment, etc.

Ste

[Alex Feldman]

@Stephen Wright _Elabor8_ i totally agree with you. any status separation between dev and testing within team leads to mini waterfall and i also would recommend use sub-task for test activities.

Another reason to keep In-Progress is it will help team to have transparent picture about current progress (usually it's very tricky to define exit criteria from Development state and as a result ticket will be bouncing between Development and Testing creating not productive environment) and common goal.