Software Testing: How much testing is enough testing? (2024)

Software testers are often plagued with the facade that software products can be a hundred percent bug-free. Oftentimes, while testing a product to ensure quality, there is uncertainty as to when a product has been thoroughly tested. Software testing is conducting a check to ensure that a software product meets the requirements as defined in the Product Requirement Document (PRD) with the intent of ensuring a bug-free product. It has been proven that no matter how elaborate and result-driven the test cases for a product may be, some tests will be missed and no matter how careful and thorough job a tester does, he will never find the last bug in a program, or if he does, he would not know it.

Many software testers, mostly new testers, due to the pressure from their project manager, stakeholders, and partners, come into the meld with the beliefs that;

• A tester’s focus is to assure the program works properly by doing complete testing.
• Also, with this complete testing, a tester can ensure that the program works correctly.
• A tester can fully test each program.

After proper test planning, meticulously following the steps in the test cases, and testing every nook and cranny of the product, it finally goes to production but fails due to some bugs found a few days after. When the software tester realizes that they didn’t accomplish the mission of “proper/ complete testing”, they become discouraged and may start questioning the integrity of their role in the company.

Then How much Testing is Enough?

As testing is all about finding errors and good test cases are more likely to find errors than poor test cases, testing myths assure testers they can test a product completely which means that at the end of complete testing, there is no error.

Oftentimes, you’ll come across those who claim that they can completely test a product by testing the product’s response to all possible inputs and also testing all possible paths to the product.

Here are two main reasons a product cannot be tested completely;

• The domain of possible inputs is too large to test.
• There are too many possible paths through the product to test.

For example, let’s use this common instance of testing the result gotten from the addition of valid pair inputs between -99 to 99. It is reported that there are 39,601 different pairs of numbers as valid inputs.

Some interesting myths about testing include:

Testing is often described as a process of verifying that the program works correctly

This description is not right because you can’t test the program thoroughly enough to verify that it works correctly. is doing a great job proving that a program is full of bugs and trying to break the program. Testers are always in a clash with project managers and sometimes programmers for bringing up fixes that need to be done from programs that are behind schedule. They claim that testers are just supposed to assert that the product works just fine and is ready for production. If a tester succumbs to this, they will fail to achieve the purpose of their expertise because they’ll likely not test the edge cases in the software product.

It sets testers up for failure

As a software tester, if you feel or think your role is to verify that a product works perfectly, you will be doing yourself a disservice, because a program cannot be a hundred percent bug-free. The tester might start feeling ineffective anytime an error is found.

Most software developers catch and fix 99% of their mistakes in a product before deploying it for testing, so it is the role of the tester to find the 1% remaining. This 1% may be neglected by the developers because they assume the end-user wouldn’t take that route while using the product. Some might even use this popular phrase; “This application is for admin, they know that they shouldn’t do that or normally end users wouldn’t do this”. Well, the fantasy of having end-users be tech-savvy is for developers or product managers but not yours as a tester. The main goal is to have a top-notch stable product.

It fosters an ineffective attitude

It has been proven in standard philosophy research that people tend to see what they want to see or expect to see. If you think your task is to find problems, you will look harder for them than if you think your task is to verify that the program has none (Myers, 1979). Let’s take a look at this scenario, we have a clock and a tester is supposed to record anytime there is a tick and there is a prize for the tester with the highest number of ticks recorded. At the end of this exercise, most testers will record ticks that never happened because they thought they saw a tick, this is called false alarm which is common to software testing. This scenario is equivalent to testing a program and the tester is praised or awarded for finding bugs, you would find plenty.

Also from the scenario, let us assume a tester would be punished for recording ticks that never occurred, the tester will miss important ticks. This is also similar to testing a program. If a tester will be punished for reporting false bugs, the tester is prone to miss real bugs.

If you want and expect a program to work, you will be more likely to see a working program and you will miss failures. If you expect it to fail, you will be more likely to see the problems. If you are punished for reporting failures, you will miss failures. You won’t only fail to report them, you will not notice them.

Moreover, it is advised that you adopt a thoroughly destructive attitude toward the program. You should want it to fail, you should expect it to fail, and you should concentrate on finding test cases that show its failures. This is an essential harsh attitude for testing.

In conclusion…

As a software tester, since you cannot find all bugs in a program, you cannot prove that a product is a hundred percent correct, it is also expensive and frustrating. So why test?

Finding problems as many as possible is the goal of a tester and the more serious the problem, the better. The product is tested properly by getting bugs fixed to ensure improved quality. It may seem that the method a tester uses is a destructive process, but in reality, it is a constructive process. The tester is beating up the product intending to make it stronger and better.