Why different testing phases are important in development

Should developers do their own testing? Hmm, this is an interesting question; the answer is definitely yes!

As a developer, if I’m writing the code and compiling it myself, I might as well test my own creation. Who else could possibly understand the complexity of my code?

However, through trial and error, I came to an important realisation, which will help answer this question; the importance of testing in general.

Let me explain the best way I know how. Cue the scene from Back to the future when the first test of the DeLorean time machine takes place. (Spoiler alert for those who haven’t seen Back to the Future.)

To set the scene: it's 1985 and Marty McFly, a teenager, visits the test site where Dr Emmett Brown will test the time machine he built for the first time. Watch the second part of the test site scene.

Source: Universal Pictures

Dr Emmett Brown, also known as Doc, designed and built the time machine while Marty McFly was the tester/Quality Assurer (QA). Doc had spent months building the time machine and had now come to the point where it needed to be tested. However, he only performed one short test. The test indicated that the machine does, in fact, work. However, without the necessary extensive testing tools that we have today, disaster struck when the time machine was used multiple times. Throughout the trilogy, Doc and McFly discovered that some risks and consequences took place, similar to any digital product and its life cycle.

Let’s ask this question: why did Doc invite McFly to witness the test? I believe it’s because he needed someone to document the test, right? He knew the value of that.

In the movie, McFly had many questions because he wanted to understand the time machine but, unfortunately, Doc didn’t answer them all.

Now, let’s imagine for a second if Doc had invited McFly while he was still building the time machine before the actual test took place. Here are the potential benefits:

1. Doc and McFly could have come up with more testing scenarios before the time machine was tested and would have documented the scenarios to deliver a better-quality build. Surely, together, they would have tested more theories before the practical test.
   
   
2. Many risk factors during the build phase would have been avoided simply by McFly asking questions. For example, they would have potentially thought of a better-suited fuel instead of using plutonium, which is illegal.
   
   
3. The building process could have been streamlined, and even the amount of rework that takes place throughout the trilogy.

This brings me to the role McFly plays in the product team as the QA. Even though he joined Doc’s team late, his ingenious travels to test out the capabilities of the first version aided the project. In doing this, Doc designs and builds a better version of the time machine. I strongly encourage you to watch the movies to better understand the analogy.

As a developer, working on a project, your goal is to ensure things work as they should. When you choose to test your own work, it’s possible that you might hold back and only test optimistic case scenarios because your viewpoint is ultimately subjective. This isn't the most ideal way to go about things, and proves the value of the QA role.

Source: Unsplash

We can also see this from a project lifecycle perspective, it's clearly illustrated how valuable the QA's role is in a coding aspect. Different scenarios are tried and tested. In doing so, QA ensures that all the bases and depths are covered in the project. Not only does this help set a good standard throughout the project, but it also ensures that a high-quality project with no defects is delivered.

To circle back, my answer remains, yes. Developers should do their own testing in the beginning phase, but should ultimately demonstrate their test to the QA team and allow them to conduct the rest of the required testing to get an objective view and ensure the standard is delivered.