Test Protocol and Results — QMS Nordic

Template — QMS Nordic T4. Scripts are pre-written; you execute them.
Why you test at all when we have tested already. Our evidence shows the platform behaves as specified. It cannot show that your configuration, your roles and your processes produce the result you need — and that is precisely the gap an auditor probes. "We read the vendor's package" is the answer that generates the finding.
Run only what your risk assessment says to run. T3 decided the depth; this executes it. A protocol that tests everything regardless of risk is not more rigorous, it is undirected — and it invites the question of why you tested the colour of a button but not who can delete a record.
Effort: 1–2 days for a High-risk categorisation. Less if you use fewer modules.

Test Protocol and Results — QMS Nordic
Document	[DOC-XXX] Test protocol and results — QMS Nordic
Software	QMS Nordic v1.5.0
Environment	[your tenant URL]
Tester	[name]
Dates	[from] – [to]

1. Before you start

☐You have a test user at each role level you use
☐You have a second test user — several tests need two people
☐You are testing in your own tenant, on the configuration you will use
☐You know your risk ratings from T3 — they decide which sections to run

Test in your real tenant, not a sandbox, unless you have a genuine reason not to. The point is to validate the configuration you will actually use. Create test records, prefix them clearly (VALIDATION-), and remove them afterwards — recording that you did.

2. Core tests — run these if your risk assessment rated anything High

2.1 Document control

2.1 Document control
#	Steps	Expected	Result
T-DOC-01	Create a document, take it through your approval route to effective	Only the approved version shows as effective; the route matches your process	☐P ☐F
T-DOC-02	Edit an effective document	A new version is created; the previous version remains retrievable; status returns for re-approval	☐P ☐F
T-DOC-03	Retrieve a superseded version	Prior content is readable and clearly marked as not current	☐P ☐F
T-DOC-04	Attempt to approve a document as its author	Blocked, if your process requires separation of duties	☐P ☐F ☐N/A

2.2 Audit trail — the one to do properly

2.2 Audit trail — the one to do properly
#	Steps	Expected	Result
T-AUD-01	Change a record. View its audit trail	Entry shows who, when, what changed, and the previous value	☐P ☐F
T-AUD-02	Attempt to edit or delete an audit entry through the interface	No means exists to do so	☐P ☐F
T-AUD-03	Ask QMS Nordic to demonstrate that a direct database alteration of an audit record is detectable	Demonstrated; you record what you were shown and by whom	☐P ☐F
T-AUD-04	Export an audit trail	Readable outside the system	☐P ☐F

T-AUD-03 needs us. Ask — it is a reasonable request and we will show you. "We asked the vendor to demonstrate audit-trail tamper detection and they did, on [date]" is a strong line. If a vendor cannot demonstrate it, that is worth knowing before you rely on the records.

2.3 Access and separation

2.3 Access and separation
#	Steps	Expected	Result
T-ACC-01	Log in as each role you use; attempt an action outside that role	Permitted actions succeed; others are refused	☐P ☐F
T-ACC-02	Confirm no records from another organisation are visible anywhere	None	☐P ☐F
T-ACC-03	Remove a test user via your leaver process, then attempt to log in as them	Access refused	☐P ☐F

T-ACC-03 tests you, not us. It is the most commonly found gap under this clause, and the only test here that a vendor package can never cover.

2.4 Electronic signature (N/A if unused)

2.4 Electronic signature (N/A if unused)
#	Steps	Expected	Result
T-SIG-01	Sign a document	Re-authentication is required at the moment of signing	☐P ☐F ☐N/A
T-SIG-02	Inspect the applied signature	Records signer, date, time and meaning	☐P ☐F ☐N/A
T-SIG-03	Modify a signed document	A new version is required and re-approval is triggered	☐P ☐F ☐N/A

2.5 AI drafting (N/A if unused)

2.5 AI drafting (N/A if unused)
#	Steps	Expected	Result
T-AI-01	Generate a draft; inspect its provenance	Identified as AI-generated, with model and generation recorded	☐P ☐F ☐N/A
T-AI-02	Attempt to make an AI draft effective without human approval	Not possible in your process — if it is, record it as a finding against yourself	☐P ☐F ☐N/A
T-AI-03	Read a generated document to its end	It ends properly, not mid-sentence	☐P ☐F ☐N/A

T-AI-02 is a test of your process, not the software. If a draft can reach effective status without a person approving it, the software will let you — and an auditor will find it.

2.6 Retention and export

2.6 Retention and export
#	Steps	Expected	Result	Evidence
T-RET-01	Export a full record set	Complete and readable without the platform	☐P ☐F
T-RET-02	Confirm export covers everything you must retain	Nothing required is missing	☐P ☐F

3. Your own workflows

The tests above cover platform behaviour. These cover your processes, and they are the ones an auditor will care about most — because they are the ones nobody else could have written for you.

3. Your own workflows
#	Workflow	Result
T-OWN-01	[e.g. Raise a CAPA from a complaint and close it]	☐P ☐F
T-OWN-02		☐P ☐F
T-OWN-03		☐P ☐F

4. Deviations

Record every failure. A failed test with a documented resolution is evidence of a working process; an absent failure record in a system that clearly had problems reads as an incomplete one.

4. Deviations
#	Test	What happened	Assessment	Resolution	Closed
D-01					☐

5. Summary

5. Summary
Tests planned	[—]
Passed	[—]
Failed	[—]
N/A (function not used)	[—]
Deviations open	[—]
Test records removed afterwards	☐

5. Summary
Role	Name	Signature	Date
Tested by
Reviewed by

QMSN-T4 · v1.5.0 · pack rev. J (2026-09-07)
Published at qmsnordic.com/legal/validation/t4-test-protocol. Cite the version above in your validation record — a pack is evidence, and evidence has to stay retrievable at the version you validated against.