Performing Testing has always been a crucial and challenging task. Thus, to perform testing effectively and efficiently, various guild lines have been presented and suggested by scholars already in the field. Numerous testing principles have been accumulated over the period of last few decades by rigorous understanding of the testing psychology.

Here, in this blog set, we would discuss in detail about these testing principles and how are they applicable in the real life scenarios while performing testing.

Before kick starting, Let us have a quick look at what can be the potential threats/problems which demands the need of testing.

– Failures can be caused due to errors in specification, design and implementation of the software.
– Errors in use of the system
– Environmental conditions
– Intentional damage
– Potential Consequences of earlier errors, defects and failures.

Now, when we know that testing activities are an inherent need of the software development process in order to achieve functional and non- functional quality aspects, let us discuss the testing principles.

Testing shall always be done differently in different context. Generally, it depends on the level of risk and impact associated with the work product. Occasionally, it may depend on the factors like deadlines, time pressure, resource availability and market needs.

A risk is something that has not yet happened but has a probable happening; it is a potential problem. When we discuss risks, we shall also consider the impact of the risk if it happens.

If these risks occur, their solution may be costlier and damaging. Therefore, risk analysis should be done prior to testing and thus accordingly testing technique and approach shall be chosen within the context.

We always have certain questions, how much testing should be done? At what time can we say that the system is fully tested? Can testing be completely done? To answer these questions we have our next testing principle.

Choice is ours:

– Test Everything
– Test Nothing
– Test some part of the software

Ideally, we shall test everything, but practically this seems impossible. Let us take an example. If a 1 digit field is to be tested, then there can be “n” no. of test cases with 26 lower case, 26 upper case and 6 special characters. Thus, leading to devise an approach which does the right amount of testing, considering the time pressure and the project budget.

Test some part of the software
Perform risk assessment to comprehend how much testing needs to be done. The efforts that need to be put into testing activities are more or less tailored by risks and cost associated with the project.

The next testing principle answers questions like: When can we start testing?

Early testing – such as early test design and review activities – finds defects early on when they are cheap to find and fix.

Defect Propagation:

Cost of Defects:

Considering the above factors, it is highly recommended to start testing in the project as soon as it is possible.

There might be areas in the project, which can be tricky and complex, thus these are the hot spots of the application for testing as they tends to exhibit the maximum number of defects. Therefore, it is an important task to identify the potential clusters.

If we have been testing for a long while with the similar set of test cases, it tends to decrease the number of defects as we move forward. After a certain stage, the same set of test cases does not find the defects anymore. Thus we might need to change the set of test cases with another set of test cases in accordance with the next set of risks to have more defects exposed.

The next testing principle answers questions like: Can i say that the software is defect free?

Above a brief to testing principles has been given, but many of these principles would already be in use within your project. Thus the blog gives a fair idea of the keys factors to testing.