From Functional Risk Assessment to Test Cases for a SharePoint Quality Register

How do you turn a functional risk assessment (FRA) into useful test cases for a SharePoint quality register as part of computerised system validation (CSV)? Here, CSV means computerised system validation, not a comma-separated values file. Start with the decisions people rely on the register to support. For each in-scope requirement and failure mode in the FRA, identify the control intended to prevent or detect it, then define a test condition and evidence that would show whether the control works in the configured environment.

The worked example below shows traceability for a SharePoint List. It focuses on the step from an FRA to protocol test cases; it is not an end-to-end validation process, a complete protocol, a prescribed document count, or evidence that a real configuration has passed. The existing SharePoint validation overview covers the broader planning deliverables; this narrower companion focuses on a reusable requirement-to-test row and three illustrative examples.

The example in scope

Assume a fictional deviation register uses a SharePoint List to track a stable identifier, owner, classification, status, due date and link to an authoritative deviation record. The broader record-versus-register boundary and planning deliverables are covered in the SharePoint validation overview linked above. This example assumes that intended-use scope has already been defined and focuses on turning in-scope FRA items into checks.

For Australian medicinal-product Good Manufacturing Practice (GMP) work, a direct check of the Therapeutic Goods Administration (TGA) page about the Pharmaceutical Inspection Co-operation Scheme (PIC/S) Guide to Good Manufacturing Practice on 30 October 2026 identified the Guide dated 25 August 2023 (PE 009-17) and stated that Annexes 4, 5 and 14 are not adopted in Australia. This identifies the adopted guide, not the applicability of every requirement to a particular product or process. Confirm the use case, any exemptions and transition provisions with the current TGA guidance; do not treat a newer international publication or proposal as an Australian requirement without checking its adoption and applicability.

Turn an FRA risk into a test case

For each in-scope FRA item, carry its requirement and failure mode into a test that challenges the control intended to prevent or detect that failure. Preserve the approved assessment rationale; do not create new risk scores or acceptance thresholds for the example.

These are illustrative requirements and expected results, not verified SharePoint capabilities or observed test outcomes. Each real requirement needs an owner, a reference to the approved intended use, and acceptance criteria appropriate to the organisation's process.

For the report check, use this synthetic fixture with a fixed demonstration clock of 15 October 2026, 09:00 Australia/Melbourne. Treat an item as overdue when its due date is before 15 October and its status is not Closed; a missing due date is a separate exception.

Expected counts are four open items, one closed item, one overdue item, one due today and one missing due date. These are arithmetic expectations for the fixture, not observations from a configured system.

Copy and complete this row for each in-scope requirement:

Derive test cases from FRA findings

1. Select an in-scope FRA finding. Use the approved assessment and its existing rationale; do not rescore the risk or create new acceptance thresholds for the test plan.
2. Extract the test-design inputs. Trace the intended function or requirement, failure mode, possible effect and existing control. Identify the configured role, data, report or workflow path involved.
3. Challenge the control. Choose positive, negative or boundary conditions that exercise the failure mode through the enabled paths relevant to intended use, such as manual entry or import. Use synthetic data for planned examples.
4. Make the protocol case executable. State prerequisites, inputs, steps, expected result, evidence to retain and the responsible owner. Keep the expected result separate from the actual result, which is recorded only during execution.
5. Check coverage and traceability. Link each test back to its FRA finding and control. Record a rationale when a risk is addressed by another control or is outside the test scope; do not imply that the example covers every platform feature.

The goal is a defensible link from an approved risk finding to a test that can challenge its control—not a complete validation package. A focused set of tests can be useful when its scope, limitations and evidence are clear.

What to do when a check fails

Suppose a duplicate DEV-2026-0001 is accepted through an enabled import path. Record the actual input, configuration version, result and evidence. Do not quietly change the expected result or describe the check as passed.

The responsible team should assess whether the duplicate can misidentify or mislink an event, identify any affected records, and decide whether use should be restricted while the issue is investigated. Record remediation and define a retest for the failed path and any affected paths. The accountable acceptance authority—not the example matrix—decides whether remaining limitations are acceptable for the intended use.

For this example, the failure and all test outcomes are unexecuted. No real SharePoint configuration, supplier evidence, risk rating or release decision is represented.

Keep the plan specific to the system

Use the matrix as a traceability aid, not a fixed package of documents or evidence that a configuration passed. If a requirement, control or relevant workflow changes, review whether the FRA finding and its linked test cases still represent the intended use. New electronic approvals, signatures, automated classification or a change to the authoritative record are not assumed in this register example.

Related reading and next step

For general risk-based computerised system validation principles, see Practical Risk-Based Computerised System Validation.

For another example of mapping functional failure scenarios to testing and procedural controls, see PharmOut's worked functional-risk assessment example (PDF). It illustrates risk-to-control mapping, not a complete test protocol or a prescribed scoring method. PharmOut is a QikSolve partner; this is supporting reading, not regulatory authority or a substitute for your organisation's approved risk method.

If you are deciding how to plan validation work for a quality system, explore QikSolve's validation-planning guidance. Your organisation remains responsible for its regulatory decisions, configuration, testing, acceptance and ongoing control.

Source to recheck before release

• TGA: Complying with the PIC/S Guide to GMP
• TGA-hosted PIC/S GMP Guide Annexes

Confirm the current source versions, jurisdiction and applicability before making a specific regulatory claim. The article's illustrative checks are not legal advice or an assessment of an organisation's compliance.