How do you calculate integration test workload?

Divide the number of test cases by the execution rate to get base hours, then multiply by one plus the retest allowance. With 120 cases at 4 cases/hour that is 30 base hours, and a 35% allowance gives 40.5 total integration test hours.

What is a good retest allowance for integration testing?

For a stable, well-documented interface 20-30% is reasonable; for first-time integrations against an unfamiliar partner system or a custom API, 40-60% is safer because early defect density is high and most failed cases get re-executed multiple times.

Why is the total higher than the base test hours?

The base 30 hours is a single clean pass. Real integration testing requires re-running cases after each defect fix, so the 35% retest allowance adds 10.5 hours, bringing the total to 40.5 hours.

What execution rate should I assume?

Simple automated assertions can run dozens per hour, but realistic integration cases — trigger a transaction, wait for the downstream system, verify the record — often land at 3-6 cases/hour, which is why the default uses 4.

Does this include test case authoring time?

No. This sizes execution only. Writing the cases, building test data, and stubbing partner endpoints are separate efforts you should estimate alongside this number.

How is this different from a system cutover estimate?

Test workload sizes the validation phase before go-live; cutover effort sizes the actual switchover tasks during the go-live window. You typically run both and add them into the overall integration plan.

Industrial Software Integration & APIs calculator

Integration Test Workload Calculator

Integration Test Workload estimates how many engineer-hours it will take to validate that two or more industrial systems — say an MES talking to an ERP, or a PLC feeding a historian — actually exchange data correctly. Test leads and integration project managers use it to size a test phase before committing to a go-live date. It multiplies a base execution time by a retest allowance, because in integration work the first pass almost never passes clean: brokers drop messages, field mappings are wrong, and you re-run cases after each fix. Getting this number right is the difference between a cutover that lands on the planned weekend and one that slips three sprints.

What this calculator does

Estimate the total hours required for integration testing including test case execution, defect verification, and regression testing across connected manufacturing systems.
Use this calculator when planning QA resources for integration testing phases, estimating UAT effort for ERP/MES connections, or scheduling test cycles before go-live.
It computes the total integration test effort in hours, including a buffer for re-running cases after defects are fixed.

Formula used

Base test execution hours = test cases / test execution rate
Total integration test workload = base hours x (1 + retest allowance / 100)

Inputs explained

Test cases to execute:
Test execution rate:
Retest and regression allowance:

How to use the result

Use it during test planning for any system-to-system integration — API contract testing, EDI/B2B onboarding, MES-to-ERP interfaces — before you lock a test window or quote a fixed-price test phase.
It assumes a roughly constant execution rate; complex end-to-end scenarios with long data-settling waits or manual reconciliation will execute far slower than simple field-mapping checks, so blend rates carefully.

Common questions

How do you calculate integration test workload? Divide the number of test cases by the execution rate to get base hours, then multiply by one plus the retest allowance. With 120 cases at 4 cases/hour that is 30 base hours, and a 35% allowance gives 40.5 total integration test hours.
What is a good retest allowance for integration testing? For a stable, well-documented interface 20-30% is reasonable; for first-time integrations against an unfamiliar partner system or a custom API, 40-60% is safer because early defect density is high and most failed cases get re-executed multiple times.
Why is the total higher than the base test hours? The base 30 hours is a single clean pass. Real integration testing requires re-running cases after each defect fix, so the 35% retest allowance adds 10.5 hours, bringing the total to 40.5 hours.
What execution rate should I assume? Simple automated assertions can run dozens per hour, but realistic integration cases — trigger a transaction, wait for the downstream system, verify the record — often land at 3-6 cases/hour, which is why the default uses 4.
Does this include test case authoring time? No. This sizes execution only. Writing the cases, building test data, and stubbing partner endpoints are separate efforts you should estimate alongside this number.

Last reviewed 2026-05-12.