We should guard against our organization becoming enamored of the idea of “spot checking”.  Spot checking, if done at all, should be based upon facts, calculations and historical record and not due to the logistical inconvenience of a hard date.  Spot checking is when we perform a cursory review of the product. Some folks call this testing – but in my mind it is not.  It is a calculated risk taking at best, and at worst recklessness.  Let me explain via an example.

Suppose you have an update to the software that has nothing to do with the core or operating system portions, but a minor function that tangentially touches other software modules. That may encourage you to test only the part that has changed and not perform any regression testing or test beyond the changes that have been deliberately or intentionally made to the software. The assumption being we made no other errors in the build or the compile. All appropriate software modules were included and nobody “fat-fingered” anything.  So you can see our decision to spot check in this case is fraught with some uncertainty. Maybe we will get lucky.

Let us take that example just a step further.  Suppose we are receiving this software from a supplier with which we have a historical record.  Suppose this supplier has routinely and consistently delivered software to our organization that has problems. Suppose further, that the software revision that is being proposed for a spot check is to address a warranty problem found in the present iteration of software. The problem we are correcting was found not in testing but in the field. This present iteration of software has only had a three or so months of production or customer exposure, when a warranty problem was found necessitating this new “maintenance” release.  Is this really a good time to spot check?  We know our previous release had problems. We also know the supplier has sent us problematic software in the past, so much so that we need a new release to fix the last release.

The probability this will be a successful release is looking fairly slim.  Without having made some large scale changes at the supplier that would mitigate our previous track record, it seems ludicrous to think a spot check is sufficient. We have all of the risks from the first part of the example, the software handling, the build, the compile and fat fingers, and all of the “risks” we feign to not know regarding the past track record. 

Spot checking is not a good technique. It may be a necessary strategy at times, but that strategy should be based upon calculated and well reason and sound arguments. In the first part of the example, spot checking could perhaps be a rational approach. What is at stake? What does our previous track record tell us?  Spot checking should be the odd exception rather than the hard and fast rule.  In the last example, you can see our decision to spot check in this case is fraught with potential problems.  Our next blog will provide some alternatives to spot checking.

This page has been translated into Spanish language by Maria Ramos  from Webhostinghub.com/support/edu