We’ve mentioned ‘exploratory’ testing a number of times but what the heck is it?
Exploratory testing is certainly not spelled with a ‘Q’ in the name so where does this fit in?
The Goal is Validation
Remember, the goal is VALIDATION, not (just) qualification.
Sometimes, verifying requirements may not provide sufficient confidence that a system will perform as needed in all cases.
Verifying requirements is generally a ‘static’ exercise.
As Scripted
Test protocols are written and executed as scripted.
They are typically re-executed when re-validation is required (sometimes with modifications to adapt to changes implemented in the application).
As we pointed out above, OQ should “challenge” requirements – demonstrate that both positive and negative aspects of requirements are examined – but exploratory testing can be effective in looking at those “edge” cases or those cases where developers say, “that will never occur” (by the way, THEY WILL!).
GAMP® 5
As mentioned previously, GAMP® 5 provides a list of considerations for all systems and, as noted, some of those may not necessarily be requirements based.
Consider a power failure or even unexpected shut-down of a PC or server.
Such an event can leave systems in very unexpected states and, when re-started, unexpected behavior can be seen.
It’s hardly possible to be very specific as to how such events are handled but, especially for critical systems handling critical data but we do want to test these events to see how they can be recovered successfully.