Handling large backlog of Jira issues

Question

We are using Jira bug tracking system and have a custom status workflow configuration. After a Jira ticket is sent to "In Testing" status and assigned to a tester and if this tester confirms a bug is fixed or feature is implemented as requested, this ticket goes into this special "In Automation" status and is kept being assigned to the same tester. "In Automation" status is something we use as an indication that we are planning to write an end-to-end or integration test for it (if we think it's worth it and makes sense).

From release to release the amount of tickets sent to automation became bigger than the amount of tickets we automated and resolved. This led to a rather large backlog of tickets in this "In Automation" status (we have them about 330 now). Clearly, we have a problem.

What do you think we should do at this point? And, overall, how do you keep track of what issues have automated tests covering it and what not?

Answer 1

You need to triage submitted request to develop automated tests, exactly like your developers triage (are they?) bugs and feature requests. Automated test is code, and should be handled exactly like any other code: version control, code review, bugs/enhancement request with prioritization, documenting, whole enchilada.

Depending how sophisticated is your workflow to handle bugs/features in your code, you might adapt same or similar (simplified) workflow for automated tests, but they are code which need to be handled as code.

If you do all this, you can measure the velocity with which you are implementing automation, and can argue to the management about staffing as compared to work volume.

You can also pinpoint that with missing automated tests, more manual efforts are necessary (or quality takes shortcuts), so missing automated test have separate cost.

Answer 2

Keeping issues open in Jira also means you cannot use most reporting tools optimal. The control-chart (to measure cycle-time) will show very high values. While you want to try to fix and close defects faster and faster.

I would create another project "Test Automation" and clone the issues there, link them and close the original issues. The benefits of having a separate project is that you can give the items a new priority, as automation of some issues might be more important than others.

Better would be to add test automation of defects to the definition of done of the developers. I would not accept defects that do not have a automated test to be closed. I understand some companies choose to have a separate test automation team, but as you describe this leads to large bottlenecks. I like to visualize bottlenecks to make everyone aware.