Infor SyteLineFree worksheetPDF, Excel, Word exportInfor SyteLine

SyteLine UAT Test Script Worksheet

User acceptance testing fails when scripts live in people's heads. This worksheet gives each scenario an ID, an expected result, a named tester, an outcome and a defect reference so go-live decisions rest on evidence.

Download:
Test IDProcessScenarioExpected resultTesterTest dateResultDefect ref
Total scripts
5
Scripts in plan
5
Count the Pass, Fail and Blocked results in the table to get your pass rate: pass rate equals passes divided by scripts run.

Filter or sort by result in Excel after export and use COUNTIF for pass rate by process. Exit criteria should be agreed up front, for example no open high severity defects and every critical process passed by a business user, not a consultant.

Plan UAT with an expert

Optional review of your UAT scope, exit criteria and defect handling.

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

How to use the tracker

List scenarios by business process using real data from your plant: an actual customer, a part with a multi-level bill of material, a vendor with partial receipts. Each script has one expected result that a tester can judge without help. Record the tester, date and outcome as you go, add the defect reference for any fail or block, and export to Excel for the daily project meeting.

  • Cover end to end flows, not single forms.
  • Use business users as testers.
  • Log a defect for every fail.
  • Retest fixed defects and change the result.

Choosing the scenarios

Start from the processes that earn or spend money: quote to order, order to ship, planning to job completion, receiving to payment, month end. Add negative cases such as wrong quantity, closed period and unauthorised user. Include integrations, label printing, EDI and reports, since those break most often. For an upgrade, build a regression pack from your highest volume daily transactions.

Exit criteria and the pass rate

Agree exit criteria before testing starts. A common set is every critical script passed, no open severity one or two defects, and an agreed pass rate on the rest, with a plan for what remains. Count passes by process to see which area is weak. A blocked script is not a pass: it means a dependency such as data, access or an interface is missing.

Common mistakes

Testing with consultant-created data that never occurs in production, letting the project team test its own configuration, accepting a pass with no evidence and closing defects without retest. Keep screenshots or document numbers for each pass, and run the final cycle on a refreshed copy of production data.

Frequently Asked Questions

How many test scripts do I need?

It depends on scope. A single site manufacturer often has between 80 and 250 scripts across processes. Aim for coverage of high volume and high risk transactions rather than a target number.

Who should run UAT?

The people who will use the system daily: planners, buyers, receiving, accounts payable, quality. Consultants can support, but business users must perform and sign off the scripts so they learn the system as well.

What is the difference between Fail and Blocked?

Fail means the system behaved differently from the expected result. Blocked means the test could not be completed because of a dependency, such as missing master data, access or a broken interface. Track both, since blocked scripts hide risk.

Can I reuse the sheet for upgrades?

Yes. Keep the same scripts as a regression pack and add new ones for changed features or customisations. Re-run the pack on each environment refresh and each patch.

If you want agents that draft test scripts from your actual transaction patterns and compare results between environments, we can scope that with your team.