EpicorFree calculatorPDF, Excel, Word exportEpicor Kinetic

Epicor Upgrade Regression Test Effort Calculator

Upgrade plans often budget for the installer and forget the testing. This calculator estimates the test hours, developer fixes and calendar days for a regression cycle from your test case count, failure rate and team size.

Your numbers

cases

Business scenarios plus custom BPMs, reports, dashboards and integrations.

min
8 %
hours

Diagnosis, change and unit test by a developer.

x

Retests include setup and checking related areas.

4 people
hours

Your results

Developer fix hours
53 hrs
Calendar days of testing
2 days
First pass test hours
44 hrs
Expected failures
17.6
Retest hours
5 hrs
Total test hours
49 hrs

Planning estimate for one regression cycle. Real upgrades may need several cycles, environment builds and sign-off time that are not included.

Save results:

Testing days vs number of testers

Sweeps Testers from 1 to 20, holding your other inputs fixed.

Upgrade readiness review

Optional: we can review your customizations and suggest where to focus upgrade testing.

Optional. The tool and every export work without this. No spam.

How to use it

Count the test cases you actually need: core transactions, then every customization, BPM, report, dashboard and integration. Estimate average minutes per case and a first pass failure rate from past upgrades. Add the effort to fix a failure, a retest multiplier and the number of testers with their productive hours. The tool returns total hours, developer effort and elapsed days.

  • Weight cases toward customizations, which fail most often.
  • Use failure rates from your own previous upgrade or patch cycles.
  • Run the estimate for pessimistic and optimistic failure rates.

The formulas

First pass hours are cases times minutes divided by 60. Failures are cases times the failure rate. Retest hours are failures times minutes per case, scaled by a retest factor to reflect setup and surrounding checks. Developer hours are failures times fix effort. Calendar days are total test hours divided by testers times productive hours per day.

Reading the chart

Adding testers shortens elapsed days with diminishing returns in practice, because environment access, data setup and defect triage do not scale. The model is linear, so treat the chart as a lower bound. If developer hours dwarf test hours, the failure rate is the real risk, and simplifying customizations before the upgrade pays back.

Common mistakes

Teams test only happy paths, skip month-end and period-close scenarios, and forget that custom reports and Excel-linked dashboards also break. Using a stale copy of data makes results meaningless. Keep a written test script per case so results can be repeated for the next cycle, and plan a second cycle for fixes.

Frequently Asked Questions

How many test cases are typical?

It depends on the modules and customizations in use. Many mid-size manufacturers end up with a few hundred scenarios once they include reports and integrations. Build from your actual process list, not a generic number.

What failure rate should I assume?

Use your own history if you have it. If not, test the rate sensitivity by running a low and a high case, since heavily customized systems usually see more failures than lightly customized ones.

Do I need more than one cycle?

Usually yes. After fixing failures you retest, and a final confirmation pass before go-live is common. Multiply the estimate by the number of cycles you plan to run.

Can automation reduce this?

For stable, repeated scenarios, automated API or UI tests can cut first-pass hours in later cycles. The setup effort is real, so it pays off mainly when you upgrade or patch often.

Netray can help generate and run regression tests against your Epicor customizations. The calculator is free either way.