Module 25 · Advanced · 8 min read
Test planning
You will be able to: List the types of testing in an ERP project; Write a test plan with environment, data, entry and exit criteria; Classify defects by severity.
- Read not done yet
- Self-check: not taken not done yet
- Lesson complete not done yet
Testing proves that what was designed in the blueprint is what was built. It is cheaper to find a wrong tax code in testing than in the first VAT return. A test plan answers who tests what, on which system, with which data, and when we can stop.
| Test type | What it proves | Who tests |
|---|---|---|
| Configuration test | Each setting is as the workbook says | Consultant |
| Process test | A single process works from start to finish, such as quotation to receipt | Consultant, then key users |
| Integration (end-to-end) | Processes connect: a sale reduces stock, creates the receivable and VAT, and reaches the reports | Consultant and accountant |
| Data migration test | Loaded balances reconcile to the old system | Accountant and consultant |
| Role and security test | Each role sees and can do only what it should | Consultant and process owners |
| Output test | Prints, PDFs, exports and labels look right on the real printers | Key users |
| Backup and restore test | A backup can be restored | Technical consultant |
| User acceptance test (UAT) | The business accepts the system | Client key users |
What a test plan contains
- Scope: processes and roles included, and what is excluded.
- Environment: which system is used. Use a separate test installation or an evaluation install. Settings, Data Mode (Live/Demo) gives a separate training database with sample data, which is useful for training but does not hold the client's real configuration.
- Test data: representative customers, items, prices, tax cases and users, including the awkward ones.
- Schedule and people: who executes, who fixes, who triages.
- Entry criteria: configuration complete, migration rehearsal reconciled, test users created.
- Exit criteria: all Must scripts pass, no open severity 1 or 2 defects, a plan for severity 3 and 4.
- Defect process: where logged, who classifies, target fix times.
Defect severity
| Severity | Meaning | Example | Response |
|---|---|---|---|
| 1 Blocker | Cannot work or amounts wrong | An invoice cannot be submitted, or VAT posts to the wrong box | Fix before go-live |
| 2 Major | Important function fails, workaround exists | Print layout cuts off the total | Fix before go-live unless agreed |
| 3 Minor | Small problem | Label wording | Fix in hypercare |
| 4 Cosmetic | Appearance only | Spacing | Backlog |
Counting coverageA distributor's blueprint lists 62 Must and Should processes and checks. The plan assigns one or more scripts to each, so every requirement ID has a test. Any requirement without a script is listed as untested and signed off by the sponsor as accepted risk.
TipBuild the test plan from the requirement register. If a requirement has no script, either the script or the requirement is missing.
Practise in the demo
- Write entry and exit criteria for the test phase of an imaginary 12-user project.
- In the demo, open Settings, then Data Mode (Live/Demo) and read what the Demo database is for.
- Open https://demo.zeyto.app/demo-app/ and sign in with the demo login. This is a public demo with sample data, so nothing you do there affects a real business.
Public demo company, sign in as admin / demoAdmin123. Data refreshes nightly.
Key takeaways
- Test by layers: configuration, process, integration, migration, roles, output, backup and UAT.
- Every requirement needs a script; every script an expected result.
- Severity decides what must be fixed before go-live.
Check yourself
3 questions on this lesson. Not timed, not the exam, and you can try again. Score 60% or more, and read the lesson, to complete it.