Foreword

Recently I’ve been observing some new silly ideas about testing – on how to do as less of it as possible or not do it at all. I don’t bother posting links here – reading those isn’t worth the time. But I’m gonna speak on the subject myself.

I grouped those ideas into 3 main categories:

• Don’t do product testing at all – just get it done right in the first place
• Don’t do product testing at all if you tested the components
• Don’t do product testing at all – your customers will tell you about the problems

Just Get It Right?

I begin testing this idea of “NoTesting” with a personal pinch.

While reading those articles I couldn’t help but notice orthographic and grammar mistakes. Yet English is the authors’ native language, and they sure have a proficiency and experience in writing. Some even have books published.

Why couldn’t they just get it right, let alone fix it?

Is it because they were paying attention to the ideas rather than presentation? Yes, indeed, human brain has its own constraints on attention and focus. So they physically couldn’t.

And so are designers and programmers. Solving complex technical problems demands all attention available. With the focus on getting one thing to work one pays the price of missing the ways it won’t work.

***

I also found broken and inconsistent links in their articles.

Why couldn’t they just get it right?

Is it because they didn’t pay attention (again) or because they were thinking that they were doing it right?

And so are designers and programmers. Sometimes things just don’t work the way we thought.

***

Apart from personal.

There’s this game of broken phone which demonstrates mutation and distortion of a message.

Why can’t they just get it right?

How hard this can be after all; you just replicate what you heard.

So do designers and programmers. They all interpret the requirements doing their best.

***

Have you watched this movie? A guy makes a deal with the Devil. He even gets 12 wishes. Every time the Devil perfectly fulfills the requirements of the wish yet completely ruining it.

They did or didn’t get it right?

While focusing on what the product should do, are you aware of what it shouldn’t?

Components Working, Right?

This idea is not completely a stranger to testing. There might be contexts where testing of components is sufficient enough not to do overall testing of the product. But, here – how does one know without some critical assessment? And that’s testing already.

Another risk is that testing at component level only misses emergent properties.

***

Have you heard of this Toyota multi-million dollars recall?

Components working, right?

No functional defects. Yet huge losses, damage to the reputation, and life-threatening problem in the product.

***

Another issue is quite obvious, but often missed in software development: rules and means that put components together might be flawed.

Components working, right? – “Right. But our deployment scripts suck. This is why we have another incident in production”.

Your Customers Will Tell You

This is not always a silly idea. Testing new formats, designs, and features through customer feedback is the right thing to do. However, this is a different kind of testing. While the line might be blurry in some cases, if you try to substitute all testing with this, you should anticipate the following forms of feedback:

• Your customers will tell you by filing a lawsuit
• Your customers will tell you by tipping government regulators
• Your customers will tell you by abandoning your products and services
• Your customers will tell you by low-ranking your brand
• Your customers will tell you by complaining publicly

And, by the way, good luck trying to reproduce a bug with description “it sucks!”