With Risk based decisions during test planning a lot of muri (overdoing) can be reduced. In a project the same software may be tested in module tests, integration tests, Factory Acceptance Test, Site Acceptance Test, Installation Qualification, Operational Qualification and Performance Qualification.
Retesting the same software several time does not always add value to that software. A Risk based approach helps to decide in which test each requirement is tested or retested.
When tests by supplier are properly documented and software versions are controlled, supplier test may be leveraged into the validation documentation. When the supplier has formally tested (and documented) all requirements the following test approach may be used for a Factory Acceptance Test:
Using the Risk priority of all requirements, the table above may be used together with software category of each requirement to determine how the function is re-tested during the FAT.
| Method | Action |
| A | Full retest |
| B | Partial retest, based on Risk Scenario |
| C | Quick test, start and stop the function |
| D | Document Check |
| E | Other, to be specified |
With each retest, the previous test documentation is checked, including a check if non-conformances are corrected. When a function has a lot of corrections, a more intense level of retest may be required than indicated by the Risk Assessment.
In many projects this approach has proved to reduce the FAT period to 25 % of the time required for a full retest, without reducing the quality of the software.
Software categories are defined in GAMP 5 as:
- 1 Infrastructure Software
- 3 Non-Configured products
- 4 Configured products
- 5 Custom Applications