I’m sure we’ve all seen headlines, read articles or been in meetings where software issues are declared to be the fault of Testing. I’ve been involved in plenty of these discussions.
Here’s an example; https://outfresh.com/knowledge-base/6-famous-software-disasters-due-lack-testing/ A cursory reading of that article and anyone with an analytical brain can see that the root cause of these “famous software disasters” is not testing in any described example, there is a collection of missed requirements, coding and user errors.
A colleague of mine had a very clear mantra of “Testing cannot cause production incidents” when we were reviewing hundreds of such incidents to learn lessons and try and prevent them happening again. It seemed that neither the operational support team or development teams agreed as we found about 30% of incident records were flagged with a root cause of “Testing”. We persisted with the “five whys” to unearth the real root cause and act appropriately. How can testers introduce code errors or define requirements incorrectly?
Am I giving Testing a get out of jail free card? Absolutely not. Of course, testers can miss errors and potential failures. These can be missed in various phases of testing too, breaking phase containment through the software development lifecycle and sometimes ending up in production. There was a separate piece of analysis that needed to be done did testing miss this potential incident and which phase of testing should it have been detected.
In all cases the risk of incidents could be reduced by better communication and all players in the software development lifecycle working closer together which we see more of in modern working practices. This also helps to stop the blame culture and businesses thinking “we could have got away with it if it wasn’t for those meddling testers”.
