Build a release test matrix

What you will learn

Cover roles, data boundaries, and regression risks.

Prerequisites: IFS Cloud essentials. No IFS login is needed for this written exercise. Estimated reading time excludes practice.

The concept

A test matrix is a compact agreement on what evidence is needed for release. It should connect each acceptance criterion to a repeatable case and recorded result. Package validation can identify configuration issues, but it does not replace business acceptance tests.

A worked scenario

The coordinator’s reference change passes its happy path. During review, the team notices that old records and a read-only role were not covered. A matrix exposes these gaps before the change reaches production.

Work through it

1. Add one row for each acceptance criterion and important failure case.
2. Record role, starting data, action, expected result, and actual result.
3. Include existing behavior that the change could affect.
4. Assign the tester, evidence link, defect reference, and final disposition.

Try it yourself

Create a six-case matrix for a new optional reference.

See a suggested answer

Cover a valid value, a blank value, the agreed maximum length, a value exceeding that limit, an existing record, and an unauthorized edit. State the expected behavior for each case before execution. Mark cases Not run until someone executes them on the recorded release.

Check your understanding

Counting planned tests as passed tests. Keep Not run, Pass, Fail, and Blocked distinct.

Expected result: a written answer that explains your decision and identifies what still needs confirmation in the actual environment.

Cleanup: none; this exercise changes no IFS data.

Sources and review status

IFS Cloud 26R1 documentation. Source consulted 2026-09-23. The scenario and exercise are original fictional examples. This concept draft has not been reviewed by an IFS specialist or executed in an IFS environment.

Apply this lesson in the handover-reference project.