In Defence of Testing

Recently, I have spent some time reflecting on the last few years of projects and reading a lot of world news and politics. As I think about these things, they morph and meld, bringing interesting observations. Of late, I’ve been struck by two events.

The first is the terrible situation where a glitch in the Fujitsu system Horizon resulted in the incorrect prosecution of sub-postmasters in the UK, leading to widespread criminal convictions, bankruptcy and even suicide. Error-created data pointing to fictitious theft and embezzlement was the direct cause of these devastating outcomes. Look at “Mr Bates vs The Post Office” or read some of the news articles for more on this.

The second is the riots in PNG, where payroll errors clipped the pay packets of public servants, resulting in a police strike. This led to riots and a declaration of a state of emergency. Troops were called in to stop what has been an escalating level of violence and looting.

So, I read these things, and as a project professional, my mind goes to a potential root cause  – a lack of comprehensive testing. Many readers may accuse me of reductionism… but stick with me here. Testing is a function that we use to mitigate the risk of error and unintended consequences. Comprehensive testing does this well; professional testers can save a business a lot of pain. Overall, I like working with experienced testers; they are skillfully difficult and point out the home truths we sometimes wish were not the case. I enjoy the push and shove of these conversations. Debate and discussion create insight and understanding that avoids major problems.

Some years ago, I worked with a large organisation with a body of practice for this function. It was a function managed by senior testers who backed their people while keeping the business safe. The function arose from a terrible implementation back in the mists of time that cost a significant amount of money and reputation. Over the years, the function was eroded and finally dismantled. One of the leaders wrote an impassioned email on the value of the group as she exited. It was a beautiful and, yes, a forlorn missive. She had lived through the consequences of poor quality and loved the organisation enough to make one last try at articulating the value.

As a project manager, I really enjoyed working with them. There was push and pull and respectful tension, which produced desired outcomes and was never personal. It was about playing the ball and being factual. There was an element of intellectual and informational integrity in these conversations. Some of those testers I’m still in contact with, and my professional life has always been the better for it.

Reflecting on this and the horrible situations I started this article with, I have been prompted to think about the last few years and my experiences in project management. Here are a few observations:

• Testing has always been a crunch point for a project, regardless of the delivery method. As the old adage goes, 9 women cannot make one baby in one month. If you reduce testing time, you must accept increased risk.
• Testing practice has become a bit hit-and-miss. I recently had a role where I had to introduce the concept of defect severity, triage and prioritisation. Getting smaller vendors and some organisations to understand these basics seems to be a challenge; it feels like these primary testing practices are overlooked by many.
• The difference between debate and dissent is a challenge to what is an investigative function. For some, the function appears to be counter to a ‘let’s all just get along’ approach to work, which can become pervasive. Alignment can risk becoming groupthink if lacking the appropriate spice. A good tester is spicy!
• Misinterpretations of Agile, DevOps and CI/CD seem to suggest that quality development replaces the need for testing. This isn’t new. When I ran a Dev team, I remember a developer swearing his code was always perfect as developed, and only the narrow-mindedness of others resulted in defects (note that developers with big egos go with the territory). Humans make mistakes, and AI misinterprets intent. There is always the need for a second pair of critical and analytical eyes. The concept of maker/ checker remains valid.
• While I’m not recommending a centralised and independent testing group, there is a need to allow the testing to function at a level of independence structurally and conceptually. Testers must be able to voice their concerns, and executive management need to understand that this is their safety net in a project.
• Lastly, project management has a role in better representing and explaining testing. Business stakeholders, technologists, vendors and customers must comprehend that testing isn’t risk elimination – it’s risk mitigation and understanding. Testing is set to a level of risk acceptance, which we (and here I include myself) need to do more to communicate.

None of this averts disaster; it only makes it less likely. So, treasure your spicy, prickly testers and listen with both ears when they worry!