The blog “Testers Do Not Break the Product” was posted on LinkedIn and there were considerable responses and exchanges.  In an effort to continue that same discourse, I post some of that exchange.

Many thought the language “breaking”, as did many others, to be unclear or ambiguous. The language in this discussion originates from the Twitter exchange. Perhaps we can refer to it as “failure”.

If the product does not fail during testing or in the field has it failed? No. The potential failure can be in the product and the product presently performs as expected. Perhaps that combination or timing of stimuli never will occur in the field.  The potential or possibility of failure of the memory write handling during power interruption is exploited by the test engineer, evoking a hard failure – the product fails to work at all (previously referred to as break).  To “fix” the product requires technical manipulation, something a customer cannot do in the field.

The product was not in the failed state prior to the test.  No, the product performed as expected until the time the specific test is executed. The failure or break did not exist before the tester performed the test.  The defect, that would allow the failure, was dormant – the opportunity for failure was there. I am sure you would agree that this instantiation of the product is failed (broken), and we can deduce (or surmise) that any iteration of this product so built may have the same latent defect that will produce under the similar conditions a similar failure (broken).  Consider this[1]:

Observer’s paradox: the observation or measurement itself affects an outcome, so that the outcome as such does not exist unless the measurement is made.

If you are saying, the possible / probable defect is in the product before the test engineer performs the testing, I would agree.  The test engineer does not add to the product, they test the product.  There resides within the product an opportunity for failure.  No matter how well constructed the product; there are opportunities for a failure.  It is arguably the test engineer’s responsibility to find how it can fail (be broken).  If that key stimuli to provoke the failure is not encountered either in testing or in the field, there is no failure – the product does not “break”.  Proof (evidence) that the stimuli are harmful to the product (or causes unintended consequences) is demonstrated by a failure of the product.  The possibility or probability of a failure exists until there is in fact a demonstration of failure – vis-à-vis a failed (broken) product.  To thoroughly verify the product our testers must find the limits.