Prevention vs Detection

Although I title this article Prevention vs Detection it could easily be titled, QA vs Testing.

All too often we get fixated on the testing and detection of defects without seeing the benefit of not introducing the defects in the first place. As more companies accept Agile practices and methodologies the importance of focusing on quality over testing will become highlighted even more so.

Thirty years ago, when I started my test management career, we used the phrase “garbage in, garbage out”. Occasionally in meetings this retro explanation of why quality assurance matters is uttered by somebody, normally a keen but inexperienced tester who cares. People nod. Everyone agrees: This time we’ll give enough time to get the requirements absolutely right.

Then something happens along the way…

GIGO Principal:

Garbage In = Garbage Out

The gigo policy still holds true today and is completely agnostic of the way you deliver (agile, extreme, waterfall…). A recent case study I conducted brought up a classic quote: “Instead of crap requirements, we now have crap user stories.”

As the world moves to a much more agile way of delivering; the art of quality becomes more important than the art of testing. Why? In order to prevent the cost of testing getting out of control. (Because that’s one thing all of us working to deliver testing will have in common).

By methodology, Agile requires an increased amount of testing throughout the delivery life cycle, compared to other delivery models. And most of it is automated. The latest World Quality Report 2018-19 (WQR) shows that there is an increased spend in testing, however given the financial climate there is a desire from most companies to reduce or maintain their current cost levels.

This is where you see the real benefit of quality management practices. In order to maintain or reduce a cost you need to prevent the “garbage in…” part of the gigo principal.

This is not new information, it was known thirty years ago. Yet still we witness many projects going down the same route every time to compete against more quick-to-market competitors.

What’s the common factor here? What’s going wrong? Ask any development team and you’ll find the same responses.

Time and time again we see organisations rush in to build without understanding enough about what the customer truly wants.

I.T. Departments, whatever their structure, are often seen as incredibly costly to the organisation, with large financial overheads. Nowadays with full automation of testing, those overheads are jumping considerably also.

Yet the project resources creating the requirements – the business owners, analysts and customers are often only temporarily available to the project, are inexperienced in writing user requirements or have little awareness of how what they write will work architecturally, or ultimately how it will capture their customer’s hearts.

With all this talk about automation, and latest trends like AI etc, we forget the human factor of project delivery.

And it’s not the requirements writers’ ultimate responsibility. That sits with the stakeholders as they hold the purse strings for all of this, including the authority to set a project in motion, allocate the correct resources to creating those user requirements, and fundamentally to accept the quality of the work that is done.

Those business authorities tend to come and go over the years, meaning the quality target is never the same.

“Software never was perfect and won’t get perfect. But is that a license to create garbage? The missing ingredient is our reluctance to quantify quality.”

Boris Beizer

This means that the general concept of quality and principle of gigo – garbage in, garbage out, is being relearned by business every few years as it is proven over and over again. The message of quality assurance has to be continually sold to different people unless an organisation puts it’s foot down and stops the constant cycle of garbage in.

So let’s put this very simply –

The more time that can be spent understanding the required outcomes, the less testing and rework that will be needed in the later stages.

Testing is still a sunken cost for any project so implementing the right prevention techniques can reduce the amount of time and effort from the very start of the program. With project costs and testing timelines always being squeezed, I believe we are now entering the true age of the Quality Specialist.

I will discuss the benefits of QA management and how it compliments Program Management in my next post. In the meantime, what do you think?

One Comment Add yours

Leave a comment