How are you managing ERP test cases alongside Jira?

Question

ERP testing can become difficult because one change may affect several connected areas such as finance, inventory, purchasing, sales, or user permissions. Teams may also need to repeat the same regression tests after every release, keep track of who tested what, record results, and connect failed tests with Jira bugs. For a small number of tests, spreadsheets may work, but as the ERP system grows, keeping test cases, test runs, results, and defects organized can become harder.

For teams already using Jira, what is the best way to manage this?

I have seen different approaches and tools. Xray and Zephyr seem useful for teams that prefer test management closely connected with Jira. TestRail is another established option for teams that prefer a separate test management system. I have also been looking at Tuskr, which provides test case organization, test runs, and Jira integration. Tuskr can create Jira issues from failed test results and link the Jira issue back to the test result.

I would especially like to hear from teams that have tested ERP systems with many modules and repeated regression cycles. What worked well, and what became difficult as the number of test cases increased?

Nick Sudo · Answer

ERP testing can become hard when there are many things to check. For example, finance, inventory, sales, and purchasing can all be connected. A small change in one area can sometimes cause a problem in another area.

I think it is helpful to keep the test cases simple and linked to the real work process. The team should also be able to see what was tested, what failed, and what still needs to be fixed.

Spreadsheets may be fine when there are only a few test cases. But when the list gets bigger, they can become difficult to manage.

I’ve also been looking at ERP tools like FlowLedgerPro. Having different business processes in one place can make the work easier to manage.

Ashik Muhammed _ AIO Tests · Answer

The thing that usually breaks first in ERP testing isn't volume, it's duplication. The same transversal test (a permission check, an approval flow, a posting rule) gets copied per module and per wave, and then the copies drift apart.

Matteo's point about keeping transversal tests in one project handles half of that. The other half is keeping one case rather than cloning it per wave, so every execution stays visible on the case itself: which cycle it ran in, the result, who ran it, and any defects raised. That history is what tells you whether a failure is new or has been recurring across waves, which matters when a finance change surfaces in inventory three cycles later.

Full disclosure: I work on AIO Tests, where each case carries that cycle-by-cycle history on its Associations tab inside Jira.

Matteo Vecchiato · Answer

Hi @Vinayak Wagh ,

Thank you for your post.

I worked in cases like your, I suggest, as you are already mentioned, the adoption of marketplace app: Xray or Zephyr.

The main difference between them is that Zephyr is based on added elements for test cases, meanwhile Xray uses the standard work items.

In the specific with ERP testing, I worked with Zephyr:

* The test cases were grouped by modules and waves (Zephyr allows to group in hierarchycal folders)
* If the Jira projects are multiple, it is best to put the transversal tests in only one project, and the specific tests (dev tests mainly) in the specific projects
* Added Zephyr custom fields to organize the tests cases

Hope it helps