6 Principles of Software Testing

Software TestingSoftware & CodingTesting Tools

This guide presents the seven fundamental Software Testing Principles that any software tester and quality assurance professional should understand.

6 Principles of Software Testing

  • Exhaustive testing is not possible
  • Early testing
  • Defect clustering
  • Pesticide paradox
  • Testing is context-dependent
  • Absence of errors fallacy

Background

When performing software testing, one must achieve optimal test results without straying from the target. But how do we know if we are using the best research strategy? To do so, we must adhere to certain fundamental research standards.

Consider the following circumstance: we are transferring a file from Folder A to Folder B. Consider all of the many ways by which we can test this.

Aside from the standard examples, you can also put the following conditions to test−

  • Attempting to transfer a file when it is open.
  • We do not have the required security permissions to paste the file into Folder B.
  • Folder B is on a shared disc, and its storage space is at capacity.
  • Folder B also has a file of the same name, and the list continues on.
  • If you have 15 input fields to compare, each with 5 potential values, the total number of variations to test is 5^15.

If you tested every possible mix, the project's Processing Time & Expenses will skyrocket. So, we require such concepts and techniques that are needed to enhance the research while optimizing the effort.

Here are the 6 Principles

1. Exhaustive testing is not possible

Well, indeed! It is not necessary to do exhaustive research. Instead, we need the least amount of research possible depending on the application's risk evaluation.

The most important question is, how to calculate this potential danger? Let's have an experiment to resolve this.

Which activity, in your view, is most probable to provoke your operating system to collapse?

I hope all of you have guessed it right and that is, opening ten separate applications simultaneously.

So, if you were testing this Operating System, you would notice that bugs are most likely to be detected in multi-tasking activities and must be carefully tested, which takes us to our next concept, clustering of flaws.

2. Defect Clustering

According to defect clustering, the majority of the defects found are contained in a limited number of units. The Pareto Principle is applied to software testing in this way: roughly 80% of the issues are identified in 20% of the units.

These problematic modules can be identified by practice. However, there are several drawbacks to this strategy.

If the same experiments are conducted repeatedly, the same test cases will inevitably cease to detect new glitches.

3. Pesticide Paradox

Repetitious use of the same pesticide combination to kill insects while farming can result in the insects gaining pesticide immunity over time, thus making the pesticides useless against insects. The same is true with software testing. If the same series of repeated checks are performed, the procedure would be ineffective for detecting new faults.

To resolve this, the test cases must be tested and updated on a regular basis, with new and varied test cases included to discover new flaws.

Testers cannot rely solely on current test methods. They must constantly strive to refine current techniques in order to make the research more efficient. However, even with all of the hard work in research, one can never say that their end-result is bug-free. To emphasize this point, let's highlight the disastrous Windows 98's public introduction program. The OS crashed as the speaker was demonstrating the OS to the public in the launch event. Do you think a corporation like Microsoft would not have carefully checked their operating system and would endanger their prestige just to have their operating system fail during the public launch?

4. Absence of Errors Fallacy

The testing philosophy says that - Testing discusses the existence of defects but not the lack of it. That is, Software testing decreases the likelihood of unexplored faults existing in a software, but even though no flaws are detected, this is not evidence of 100% accuracy.

But what if you work super hard, taking all care, to ensure that the tech product is bug-free? And the program does not fulfill the clients' demands and expectations.


This brings us to our next theory, which says that the absence of error is important.

5. Early Testing

Testing should begin early in the Software Development Life Cycle so that any flaws in the specifications or design phases are discovered early on. It is also less expensive to patch a flaw in the early phases of testing. But when does one begin testing? It is advised that you begin looking for bugs as soon as the specifications are specified.

6. Testing is context-dependent

Testing depends on context, which implies that testing an e-commerce platform may vary from testing a commercial application. All of the built software is not the same. Depending on the application form, you can use a particular methodology, methodologies, methods, and forms of testing. For example, testing a POS device in a retail store is not the same as testing an ATM machine.

Myth: 'Principles are just guidelines. They can not be practically implemented.'

This is completely false. Test Principles will assist you in developing a successful Test Strategy and writing error-catching test cases. However, mastering the testing concepts is similar to learning how to drive for the very first time.

When you first start learning to drive, you pay close attention to everything, such as gear changes, rpm, clutch handling, and so on. However, with practice, you just need to concentrate on driving and the rest will come naturally. So much so that you're also conversing with other people in the car.

The same is true for principles of testing. Experienced testers have internalized these ideas to the point that they adopt them without ever worrying about them.

V-Model in Software Testing

The V Model is a highly organized SDLC model that includes a testing period in addition to each production phase. The V model is an evolution of the waterfall model in which research is performed on every stage concurrent with design and development sequentially. It's referred to as the Validation or Verification Model.

Key Terms

  • SDLC: SDLC is an abbreviation for Software Development Life Cycle. It is the series of tasks performed by Programmers in order to design and create high-quality applications.
  • STLC: STLC is an abbreviation for Software Testing Life Cycle. It contains a set of works performed methodically by testers to validate the software product.
  • Waterfall Model: A waterfall model is a sequential model that divides software development operations into various phases. Each stage is intended to be used for a particular operation. In the waterfall model, the testing process begins only after the system's specifications have been met.

Example to Understand the V Model

Assume you've been tasked with developing custom applications for a customer. Regardless of your technical experience, you would take the following sequence of actions to complete the mission.

Different phases of the Software Development Cycle
Activities performed
Gathering Stage
Collect as much input as possible from the customer about the details and configurations of the requested program. This is merely the specifications gathering point.
Design Stage
Plan the programming language such as Java, PHP, .NET, and the database such as Oracle, MySQL, and so on, which will be appropriate for the project, as well as certain high-level functions and architecture.
Build Stage
Following the concept stage, there is the build stage, which is nothing more than simply coding the software.
Test Stage
Following that, you validate the application to ensure that it is designed in accordance with the client's requirements.
Deployment Stage
Install the program in the appropriate setting.
Maintenance Stage
Once the program is operational, you may have to modify the code taking inputs from the customer.

This is what is known as the waterfall method of the software development lifecycle.

Problem with the Waterfall Model

As you can see, testing in the model begins only after installation is complete.

However, if you're working on a big project with dynamic structures, it's possible to overlook important information during the gathering process. In both situations, the customer may get a completely incorrect product, and you may have to restart the task. Instead, if you correctly mention the specifications but make significant errors in the testing design, you may have to restart the work. To fix the flaw in the creation and design of your applications, you will have to rebuild the whole software.

Thousands of project evaluations have shown that faults incorporated during specifications and construction account for over half of the overall number of errors.

Furthermore, the costs of repairing a fault rise over the development lifecycle. The earlier in the life cycle a flaw is discovered, the less expensive it is to repair it. "A stitch in time saves nine," as the saying goes.

Solution − The V Model

To resolve this issue, the V model of testing was introduced, in which each step of the Development life cycle corresponds to a testing phase.

This image is necessary to show you why it is called "the V-model".

  • The left side of the model shows the "Software Development Life Cycle"- SDLC
  • The right side of the model shows the "Software Test Life Cycle" - STLC
  • The entire structure/flow-chart looks like a V, hence the name "Vmodel".

Aside from the V model, there are iterative development models in which development is done in stages, with each step adding features to the program. Each process includes its own series of implementation and testing exercises.

Rapid Application Development and Agile Development are two good examples of the iterative development lifecycles.

Conclusion

There are various models for the development life cycle. The development model chosen for a project is determined by the project's objectives and priorities.

  • Testing is not an independent action; it must be tailored according to the project's growth style.
  • Testing can be done at all stages, from the gathering phase to the maintenance phase, in every model.
raja
Published on 13-May-2021 12:03:07
Advertisements