2

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?

  • Are you saying that you are required to automate the regression testing of every single bug fix? – Joe Strazzere Sep 20 '17 at 20:54
3

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.

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.

  • Another project is actually a nice idea. We are also thinking about giving Xray or Zephyr plugins a try to solve this problem of "connecting" Jira issues and actual tests. Thanks! – alecxe Sep 20 '17 at 16:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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