Press "Enter" to skip to content

Myth: “code must be tested by someone else”

… and thus, by dedicated testers

Today I’d like to debunk a myth that says that when you develop software you need “another pair of fresh eyes” to test it. Following this thread, dissociating so clearly development and testing leads to shamelessly requesting testing to be done by testers.

Where does the myth comes from? Critical-safety software

I must admit that there is some historical truth behind this train of thought… Namely in fields where safety is critical: military, space, nuclear plants and the likes. We should note that in such fields, as a direct consequence to the criticality of the application, the budget is simply orders of magnitudes bigger than in common projects: it’s truly another world. To give you a glimpse of how different this world is, this is the world where B-Method and Coq belong to, enabling to formally prove that the program is correct — that the program is doing what it is expected to do.

Needless to says, this is costly. But again, this is another world, where so much is at stake (usually lives) that the stakeholders feels OK with paying thousand times more money than for “just” productivity software.

But that’s not all! Other things that comes from world of critical safety software are processes that ensures that reviewing and testing are taken very seriously. Basically, every step of the software development must be handled by different people: writing spec, reviewing spec, writing code, reviewing code, writing tests, reviewing tests…

Does it sound familiar? Having two different people writing code and testing it as “something obvious”?

Yes, that’s the myth I want to debunk today.

Your business is not subject to nuclear meltdown

I hope I made the point in the previous section that such processes come from the critical safety software world.

These processes really do not make sense outside of the critical safety software world.

And that’s simply because it’s the only place where it’s deemed acceptable to spend that much money given the risks. You know, critical safety risks. Besides, even in that case you can still have dumb bugs that cost $370M — hello Ariane 5!

For all the other normal, less-critical projects, you gotta do with an equally normal budget.

It’s not about who, but about how and when

The other day my good friend Sam Joch was giving a talk at the Meetup Agile Testing Paris. He was sharing his thoughts about how he saw quality as a developer.

In French —

To him, product and quality are core parts of the developer’s job. Of course, I completely agree with him.

He describes — as a normal state of affairs — situations where developers are writing the test cases against which they will develop new features.

This totally caught the attention of the audience.

During the Q&A session, Sam got a question specifically about how biased developers were if they wrote the test cases themselves — stating this was going against all wise ways of working.

If you have not already, please note that this comment is exactly the myth I want to debunk in this post.

I couldn’t have thought of a better answer than Sam’s:

The developer is biased because he wrote the code before the test!

Indeed. If you do the work in the good order, there is no reason you get biased when writing the tests.

Another way to look at it: as a developer you’ve got to define the feature before thinking of how you will implement it. Thus test definition comes first, before even thinking of how the code will be like.

To sum it up

“The people writing code and the people testing it cannot be the same people”

… which is close to mean:

“Developers don’t test; you need dedicated testers”

This is wrong because:

  • This is overly costly and unnecessary. The rationale behind this way of thinking comes from critical safety software where the consequences of failure are literally inacceptable, hence making sense to spend an incredible amount of money. No “normal” project has that much amount of money, and this is normal because the consequences of failure are much less dramatic.
  • You don’t have to have two different people to avoid bias. You only need to think in the good order: think first of the feature itself and about how it will be tested, and only then about how it will be implemented. Applying well-known good engineering practices like TDD, Test First, BDD will naturally lead to this good order.

Liked this article? Show it!

Please clap 👏 and share the article! It is because of you that I put my heart and soul into writing.

And follow me on my blog to be notified when I publish new articles!

Thank you so much!

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *