Why shouldn’t developers test the code they wrote?

What comes to your mind when you hear the term “Program”?

For most of us, it’s a Software Program! But the term “Program” is not limited only to the world of software. The term has other contexts too.

Consider a Public program’s schedule for example.

6:00 pm- Prayer

6.30 PM – Welcome Speech

7:15 pm – Dinner

8:30 pm – Keynote lecture

9:30 pm – Q&A

10:00 pm – Adjourn

Most of the time, these types of programs are planned thoroughly and these schedules are sent out to people as a part of invites and public notice. But there is no guarantee that a public program will unfold in the same way as planned, there could be many factors affecting the actual execution of the program.

In contrast, though, Software Programs have to be incredibly precise because computers take every programmed instruction literally.

What is Software Programming?

Programming is foresight. 

Foresight is the general ability to accurately guess likely outcomes and plan for them. One of the ways adopted by developers to keep getting good at programming is by following the steps of computational thinking. 

The paradigm of programming, as of science, is “if-so-then-so.”

Both scientists and programmers talk about the future. A Scientist – in  a law, quotes “this will happen.” A Programmer – in a program, would want to “make this happen” if a certain condition is encountered.

Programming is comparable to writing a recipe for a cake, and not baking the cake. Let us look at a sample recipe for baking a cake.

  • IF THERE ARE LARGE EGGS, THEN USE 6 LARGE EGGS;
  • ELSE IF THERE ARE  MEDIUM EGGS, THEN USE 7 MEDIUM EGGS;
  • ELSE IF THERE ARE SMALL EGGS, THEN USE 8 SMALL EGGS;

The programmer’s recipe must be

Unambiguous

“IF THERE ARE AT LEAST 6 LARGE, EGGS, THEN USE 6 LARGE EGGS;”

Complete

“What happens if there are not sufficient eggs of any size? Does the computer go shopping? Borrow from a neighboring computer? Stop in mid-recipe?”

Terminate

“ELSE GO TO THE STORE AND BUY MORE EGGS?”

Widely applicable

“Any human baker knows that we could use 3 large eggs and 4 small ones, but the computer knows nothing unless told—by the programmer. What about 2 large, 3 medium, and 2 small? The more different contingencies, the more widely applicable the program—which helps pay the cost of programming”

Created in a controlled way

For instance, we might express the quantity of eggs by weight, rather than by count:

USE BETWEEN 340 AND 380 GRAMS OF EGG

By reducing many separate cases to a few, we receive more assurance from fewer tests.

Verifiable

It bakes a cake, not a brick or biryani.

Leaves kitchen clean

As contingencies grow – assurances become difficult to find.

From it above example, it’s possible to understand that,

Writing a recipe is what programmers do, and baking the actual cake with the given recipe is what testers do. Click To Tweet

Many aspects, factors, and conditions might go wrong while executing a given recipe as per the above example. There is no guarantee that things go as per the planned recipe.

Programming is more than communicating with computers.

We ask computers to do things never done before to discover that the future is not as simple as the past.

New ideas emerge.

Because of new desires or old errors, we tend to modify programs.

Far more effort may be spent in modifying than in original writing.

So, programmers not only write for the machine but very much for future programmers.

Developers have a building mindset more than a sampling mindset. Good testing involves the right sampling and experimentation.

After understanding all qualities that ideally a programmer’s recipe must address while writing code, it may not be always possible to adorn a Tester’s hat and bring a Tester’s mindset to test the program they just wrote. At the max, they may write unit tests for their methods in the code. But it may be too overwhelming for a programmer for:

  • Performing more experiments on the same code, 
  • Say testing out the methods in the code under various conditions, 
  • Assessing the performance of a function in those conditions, 
  • Evaluating a user’s reaction to a function’s performance, 
  • Assessing the usefulness of an output to a user and if the objective of building that piece of code was met

Doing the above need people in another role, A tester’s role, with a different mindset, attitude, and skillset.

4
0 Shares:
You May Also Like