There seems to be much ducking and diving when, for example, an issue comes up in testing. So is it a deviation or not?
On the one hand there is the tendency to avoid raising a deviation at all costs; it looks bad; it is a lot of work; I am in a hurry etc. At the other extreme is the classic test script error, I had one the other day, I was asked if because the word “the” has been missed off the test script, that would warrant a deviation being raised. The quick answer is “no”, but on further investigation it turned out that the “the” was missing from the system response and that the test script had in fact correctly included “the” in the expected response. So it is hardly surprising that there a lot of ambiguity around deviations especially when testers can be less than clear about what actually happened.
I try to keep it simple, if the system is operating correctly to specification then generally it is not a deviation unless the tester failed to follow testing procedures. However it needs to be made very clear on the test script what happened, the test script can be marked up appropriately and it should be explicitly stated that the system is working according to requirements. If there is any doubt, or the explanation is so long that it does not fit on the test script, then it is better dealt with as a deviation.
Deviations are good, not something to be avoided. Why? Because for a reviewer, auditor or inspector it is the opportunity to explain to them what went wrong, the root cause, the remedial actions (if any) required and make everything crystal clear. Most importantly it demonstrates that you are in control. It is my belief that a lot of the deviation avoidance which occurs is because of the over-bureaucratic procedures which are in place in many businesses, something which an electronic document management system such as ComplianceControl Centre can make much less painful.