Answer
A workable pattern for many shops is a full restore test to an isolated LPAR or a separate partition quarterly, with lighter spot checks, restoring a single critical library or IFS directory, done monthly in between. The isolated partition matters because testing a restore against production risks collisions with live objects and job names, and it does not prove anything about disaster recovery if the "test" only ever happens on the system that is supposed to fail. Buyers should ask whether the software can automate provisioning a test environment, or at least script the restore sequence so it does not consume a full day of an administrator's time each quarter.
Documentation is the part that gets skipped under deadline pressure, and it is exactly what an auditor or cyber insurance underwriter will ask to see. A useful restore test report captures what was restored, how long it took, whether the application came up cleanly, and who verified the result, ideally exported automatically rather than typed up after the fact from memory. It is also worth testing restores under a degraded scenario occasionally, missing a volume, a corrupted save file, a partial journal chain, since a clean test every time proves less than a test that occasionally forces the team to work through a real problem.