How to test an ERP system
Direct answer
Shipped untested, an ERP system pays employees the wrong amount, or nothing, from its payroll module, and lets an attacker list and take files from the ERP environment through an internet-facing component left on a version with a known exploited vulnerability. 9 tests are mandatory here, each tied to a risk in the map below. After the release smoke check, start the risk tests with regression tests: every patch or configuration change can shift the payroll, posting and period-close totals that the next pay date and month-end report rely on.
9 mandatory testsfirst: regression suite
What counts as an ERP system
An ERP system here is one system of record for finance, inventory, procurement and manufacturing, used through web and desktop clients and an API, that holds company money and employee personal data. It counts when payroll, supplier payments or general ledger postings run inside it, including the supplier and employee self-service portals and the feeder interfaces that post into the ledger. A small-business bookkeeping tool with no payroll run and no self-hosted portals is out of scope, and so is a standalone CRM.
Adjacent product types not covered here
- e-signature service: An e-signature service binds signers to documents, so consent disclosure and tamper evidence lead instead of payroll amounts and ledger postings.
- identity and access management service: An identity and access management service signs users in to other apps, so a stolen session token or skipped password check leads instead of an internet-facing ERP component left unpatched.
- accounting and invoicing SaaS: An accounting SaaS keeps the books of small businesses from bank feeds, so duplicated feed imports and tax return submission rules lead instead of pay rules and module cutovers.
Risk map
| Risk | Grade | Note | Evidence | |
|---|---|---|---|---|
| Money leaves or fails to arrive money-loss | money | secondary | A payroll module run on the ERP pays employees the wrong amount, or nothing. | |
| Personal or sensitive data exposed data-breach | data | primary | An internet-facing ERP component left on a version with a known exploited vulnerability lets an attacker list and take files from the ERP environment. | |
| Records silently wrong data-corruption | data | secondary | A feeder-system interface carries fewer fields than the legacy one, so general ledger postings arrive incomplete and staff patch them by hand. | |
| Users or operators act on wrong numbers wrong-decisions | trust | secondary | Finance cannot produce auditable statements from the new ledger, and its reports rest on inaccurate postings. |
Mandatory tests (9)
Step 1: release smoke tests
Why:money-loss
Done when: After every deploy, a test payroll run for a fixed set of employees produces the expected net pay for each person.
Tool class: browser automation. Who usually runs it: QA engineer.
Step 2: regression suite
Done when: The payroll, posting and period-close cases rerun on every release, and a single difference in totals blocks it.
Tool class: test management. Who usually runs it: QA engineer.
Step 3: unit tests
Why:money-loss
Done when: Each pay rule returns the expected amount for fixed edge cases: mid-period hire, retroactive raise, unpaid leave and termination.
Tool class: unit framework. Who usually runs it: developer.
Step 4: end-to-end functional tests
Why:money-loss
Done when: Procure-to-pay and hire-to-pay scenarios run with real pay rules and real users, and every invoice and payslip matches the expected amount.
Tool class: browser automation. Who usually runs it: QA engineer.
Step 5: data integrity and migration testing
Why:data-corruptionwrong-decisions
Done when: After migration, the trial balance, open payables and employee records match the legacy system to the cent and to the record.
Tool class: data validation. Who usually runs it: QA engineer.
Step 6: compliance checks
Why:wrong-decisionsdata-breach
Done when: An auditor can trace each line of the month-end report to its source postings, and the patch level of every module is recorded against the vendor's advisories.
Tool class: test management. Who usually runs it: product manager.
Step 7: integration tests
Why:data-corruption
Done when: Every field sent by each feeder system arrives in the ledger posting, and a missing required field rejects the batch with a visible error.
Tool class: API client. Who usually runs it: developer.
Step 8: security scanning
Why:data-breach
Done when: The scan report for every internet-facing ERP portal shows no open high findings and the latest vendor security patch applied.
Tool class: DAST scanner. Who usually runs it: security specialist.
Step 9: penetration testing
Why:data-breach
Done when: An unauthenticated tester cannot reach any file, report or servlet behind the supplier or employee self-service portal.
Tool class: proxy. Who usually runs it: security specialist.
Recommended and optional tests
contract testsrecommended
Becomes mandatory when a third feeder system is added.
accessibility testingrecommended
Becomes mandatory when the ERP serves public sector employees under accessibility rules.
performance and load testingrecommended
Becomes mandatory when outage-under-load evidence for close or payroll peaks is attached.
device and browser compatibilityrecommended
Becomes mandatory when users switch between the desktop client and web app for the same tasks.
resilience and failure testingrecommended
Becomes mandatory when dependency-failure evidence for bank or tax interfaces is attached.
exploratory testingoptional
Optional: helps find posting paths the scripted cases miss.
payment and money-flow testingoptional
Optional: helps before a new bank interface goes live, no payment-run incident is attached yet.
Not needed and why
Not needed: no attached risk comes from users misreading screens. Becomes recommended when a self-service portal redesign changes how claims are submitted.
Not needed: assumes one country's tax and pay rules. Becomes recommended when a second country's legal entity goes live.
offline and poor-network testing
Not needed: users work online on the corporate network. Becomes recommended when warehouse scanners record stock moves offline.
Order of work
First release
- release smoke tests: After the deploy, run a test payroll for a fixed set of employees and compare each person's net pay with the expected amount.
- regression suite: Rerun the payroll, posting and period-close cases on the release and block it on any difference in totals.
- unit tests: Run each configured pay rule against a mid-period hire, a retroactive raise, unpaid leave and a termination and compare each amount with the expected one.
- end-to-end functional tests: Have real users run procure-to-pay and hire-to-pay scenarios on real pay rules and match every invoice and payslip to its expected amount.
- data integrity and migration testing: After the migration, match the trial balance, open payables and employee records to the legacy system to the cent and to the record.
- compliance checks: Have an auditor trace each line of the month-end report to its source postings, and record the patch level of every module against the vendor's advisories.
- integration tests: Send a batch from each feeder system, confirm every field arrives in the ledger posting, and confirm a batch with a missing required field is rejected with a visible error.
- security scanning: Scan every internet-facing ERP portal and confirm no open high findings remain and the latest vendor security patch is applied.
- penetration testing: Have an unauthenticated tester try to reach files, reports and servlets behind the supplier and employee self-service portals.
Ongoing cadence
- release smoke tests: After every deploy, before the next payroll run.
- regression suite: On every patch and configuration change.
- unit tests: After each change to a pay rule.
- end-to-end functional tests: Before any change to pay or payment rules goes live.
- data integrity and migration testing: Before each migration or module cutover.
- compliance checks: At each month-end close and when the vendor publishes a new security advisory.
- security scanning: When a vendor security patch is released and when a new portal is exposed to the internet.
- contract tests: When a third feeder system is added to the ledger.
Tools
Listed alphabetically inside each test type, filtered to the tests above and to the platforms of ERP system (web, desktop, api). Not recommendations.
release smoke tests
regression suite
- CypressBrowser-based end-to-end testing with a visual runner. webfreemium
- DeepEvalUnit-style evaluation for LLM applications. apiopen-source
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
- TestRailTest case and run management. webiosandroidapicommercial
- XrayTest management inside Jira. webiosandroidapicommercial
unit tests
end-to-end functional tests
- ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
- BrowserStackCloud of real devices and browsers. webiosandroidcommercial
- CypressBrowser-based end-to-end testing with a visual runner. webfreemium
- DeepEvalUnit-style evaluation for LLM applications. apiopen-source
- LambdaTestCloud browser and device grid. webiosandroidcommercial
- PercyVisual review of UI changes. webcommercial
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- PostmanAPI client with collections and scripted assertions. apifreemium
- PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
- SeleniumWebDriver-based browser automation. webopen-source
data integrity and migration testing
- dbt testsTests on warehouse models inside dbt. apiopen-source
- Great ExpectationsData validation with declarative expectations. apiopen-source
integration tests
- Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
- JestJavaScript test runner with mocking and snapshots. webapiopen-source
- JUnitTest framework for the JVM. apiandroidopen-source
- PostmanAPI client with collections and scripted assertions. apifreemium
- pytestTest framework for Python with fixtures and plugins. apiopen-source
- VitestTest runner for Vite-based JavaScript and TypeScript projects. webapiopen-source
security scanning
- Burp SuiteProxy and scanner for web application security testing. webapifreemium
- GarakProbing LLM applications for prompt injection and leakage. apiopen-source
- mitmproxyInteractive HTTPS proxy. iosandroidwebapiopen-source
- OWASP ZAPDynamic application security scanner. webapiopen-source
- SchemathesisProperty-based testing from OpenAPI and GraphQL schemas. apiopen-source
- SemgrepStatic analysis with custom rules. apiwebiosandroidfreemium
- SnykDependency and code vulnerability scanning. apiwebiosandroidfreemium
- TrivyScanner for containers, dependencies and configuration. apiopen-source
penetration testing
- Burp SuiteProxy and scanner for web application security testing. webapifreemium
contract tests
- PactConsumer-driven contract testing with a broker. apiopen-source
- PostmanAPI client with collections and scripted assertions. apifreemium
- SchemathesisProperty-based testing from OpenAPI and GraphQL schemas. apiopen-source
accessibility testing
- axe-coreAccessibility rules engine for automated checks. webopen-source
- LighthouseAudits for accessibility and performance in Chrome. webopen-source
- Pa11yCommand-line accessibility testing. webopen-source
performance and load testing
- ArtilleryLoad testing with YAML scenarios. apiwebfreemium
- GatlingLoad testing with Scala, Java or Kotlin scenarios. apiwebfreemium
- JMeterLoad testing tool from the Apache Foundation. apiwebopen-source
- k6Load testing scripted in JavaScript. apiwebopen-source
- LighthouseAudits for accessibility and performance in Chrome. webopen-source
- LocustLoad testing scripted in Python. apiwebopen-source
device and browser compatibility
- ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
- BrowserStackCloud of real devices and browsers. webiosandroidcommercial
- LambdaTestCloud browser and device grid. webiosandroidcommercial
- PercyVisual review of UI changes. webcommercial
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
- SeleniumWebDriver-based browser automation. webopen-source
resilience and failure testing
- Chaos MeshFault injection for Kubernetes. apiopen-source
- GremlinManaged fault injection. apicommercial
- ToxiproxyTCP proxy for simulating network failures. apiopen-source
What to send to the person who will test
Send the checklist and the brief below. The printable checklist for ERP system has the same 9 items with checkboxes.
Download the checklistMarkdownCSVBrief (Markdown)
Acceptance criteria wording
A release of the ERP system is accepted when a test payroll for the fixed employee set produces the expected net pay for each person and the payroll, posting and period-close cases show no difference in totals. Every field from each feeder system arrives in the ledger posting, and an unauthenticated tester cannot reach any file or report behind the supplier or employee self-service portal.
Brief
# Test brief: ERP system Product type: ERP system. Finance, inventory, procurement and manufacturing in one system. Risk map and evidence: https://howtotestaproduct.com/how-to-test/erp/ Printable checklist: https://howtotestaproduct.com/checklists/erp/ Run these 9 mandatory tests in this order. A test is done only when its done condition is true on the build you will release. 1. release smoke tests (risks: money-loss). Tool class: browser automation. Usually run by: QA engineer. Done when: After every deploy, a test payroll run for a fixed set of employees produces the expected net pay for each person. 2. regression suite (risks: money-loss, data-corruption). Tool class: test management. Usually run by: QA engineer. Done when: The payroll, posting and period-close cases rerun on every release, and a single difference in totals blocks it. 3. unit tests (risks: money-loss). Tool class: unit framework. Usually run by: developer. Done when: Each pay rule returns the expected amount for fixed edge cases: mid-period hire, retroactive raise, unpaid leave and termination. 4. end-to-end functional tests (risks: money-loss). Tool class: browser automation. Usually run by: QA engineer. Done when: Procure-to-pay and hire-to-pay scenarios run with real pay rules and real users, and every invoice and payslip matches the expected amount. 5. data integrity and migration testing (risks: data-corruption, wrong-decisions). Tool class: data validation. Usually run by: QA engineer. Done when: After migration, the trial balance, open payables and employee records match the legacy system to the cent and to the record. 6. compliance checks (risks: wrong-decisions, data-breach). Tool class: test management. Usually run by: product manager. Done when: An auditor can trace each line of the month-end report to its source postings, and the patch level of every module is recorded against the vendor's advisories. 7. integration tests (risks: data-corruption). Tool class: API client. Usually run by: developer. Done when: Every field sent by each feeder system arrives in the ledger posting, and a missing required field rejects the batch with a visible error. 8. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist. Done when: The scan report for every internet-facing ERP portal shows no open high findings and the latest vendor security patch applied. 9. penetration testing (risks: data-breach). Tool class: proxy. Usually run by: security specialist. Done when: An unauthenticated tester cannot reach any file, report or servlet behind the supplier or employee self-service portal. Acceptance criteria wording: A release of the ERP system is accepted when a test payroll for the fixed employee set produces the expected net pay for each person and the payroll, posting and period-close cases show no difference in totals. Every field from each feeder system arrives in the ledger posting, and an unauthenticated tester cannot reach any file or report behind the supplier or employee self-service portal. Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file). Licence: CC BY 4.0.
For founders: what to forward and what to ask back. For product managers: turning this page into tickets.
Questions about testing an ERP system
What testing does an ERP system need?
9 tests are mandatory, starting with a test payroll after every deploy and the regression suite on payroll, posting and period-close totals. Each is tied to one of the 4 risks in the map: wrong or missing pay, incomplete ledger postings from feeder interfaces, reports built on inaccurate postings, and file theft through an internet-facing ERP component left unpatched. Contract, accessibility, performance, compatibility and resilience tests are recommended, each with the event that makes it mandatory.
What is the minimum testing for an ERP system at MVP stage?
The minimum is the 9 mandatory tests once payroll runs in the ERP, other systems post into the ledger and a supplier or employee portal is exposed. Before the first module cutover, data integrity testing must match the trial balance, open payables and employee records to the legacy system. Exploratory testing and payment and money-flow testing are optional at that stage.
Which tests in a vendor test plan for an ERP system are not needed?
Usability testing is not needed while no attached risk comes from users misreading screens, until a portal redesign changes how claims are submitted. Localization testing is not needed while one country's tax and pay rules apply, until a second country's legal entity goes live. Offline and poor-network testing is not needed while users work on the corporate network, until warehouse scanners record stock moves offline.
What should I send to the person who will test an ERP system?
Send the fixed set of test employees with their expected net pay, the pay rule edge cases (mid-period hire, retroactive raise, unpaid leave, termination) and the list of feeder systems with their required fields. Add the legacy trial balance, open payables and employee records for the migration match, and the address of every internet-facing portal for the security scan and penetration test.
When is test automation worth it for an ERP system?
Automation pays where the same check repeats on every patch and configuration change: the test payroll after each deploy and the payroll, posting and period-close regression cases. The end-to-end procure-to-pay and hire-to-pay runs need real users and real pay rules before go-live, and the month-end audit trace is signed off by people.
Evidence
ev-0233regulatorsecondary
Lessons Learned from the Transformation of Pay Administration Initiative, Treasury Board of Canada Secretariat
Government lessons-learned report on a public service pay system built on an ERP HR and pay module; it names the risk that employees receive incorrect or no pay. Supports money-loss for ERP systems with payroll.
published undated · verified 2026-10-07
ev-0231post-mortemsecondary
Oracle E-Business Suite Zero-Day Exploited in Widespread Extortion Campaign, Google Threat Intelligence Group (Mandiant)
Threat intelligence write-up: an extortion group exploited a vulnerability in an ERP suite and sent executives file listings from victim ERP environments as proof of theft. Supports data-breach for ERP systems with internet-facing components.
published 2025-10-10 · verified 2026-10-07
ev-0232regulatorprimary
CISA Adds Seven Known Exploited Vulnerabilities to Catalog, CISA
These types of vulnerabilities are frequent attack vector for malicious cyber actors and pose significant risks to the federal enterprise.
Regulator alert listing an Oracle E-Business Suite vulnerability as known to be exploited. Supports data-breach for ERP systems and the need to track patch level per module.
published 2025-10-06 · verified 2026-10-07
ev-0234regulatorsecondary
DOD Financial Management: Implementation Weaknesses in Army and Air Force Business Systems Could Jeopardize DOD's Auditability Goals, U.S. Government Accountability Office
Government audit report on ERP rollouts: it records deficiencies in data accuracy, an inability to produce auditable financial reports, manual workarounds, and an interface specification with less functionality than the legacy one. Supports data-corruption and wrong-decisions for ERP systems.
published 2012-02-28 · verified 2026-10-07
Disclaimer
This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.