Course Process

Fundamental Principles of Software Testing

The principles of software testing define the instructions for the testing teams to find the errors or effects of software by performing testing in an effective way. There are basically 7 basic principles of software testing which helps to follow the right strategy to test to achieve maximum optimum results:

1. Testing shows the presence of defects.
Testing can show that defects are present in the software, but it cannot ensure that there are no defects in the system. It reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, it is not a proof of correctness.

It is possible that even testing done for multiple times resulted in no new defects found, but that doesn’t ensure software to be state 100% bug-free.


2. Exhaustive testing is impossible.

Exhaustive Testing takes limitless efforts therefore testing functionality with all combinations of inputs(valid and invalid combinations) with preconditions is not feasible except the trivial cases.

That means software can never be tested with all possible cases, thus test strategy for testing is made which defines the testing approach to be performed based on the risks and priorities using different techniques.


3. Early testing

Testing activities should start as early as possible in the software development life cycle. Early testing finds defects early when they are cheap to find and fix. The main motive here is to find as many failures as possible early in the life cycle so that majority of the defects in the software are identified and fixed.

It is needed that software testing should start at the initial phase i.e. requirement analysis phase parallel to the software development process.


4. Defect clustering

It states that a small number of modules contain most of the defects or show the most operational failures. This can happen because an area of the code is particularly complex and tricky, or because of frequently changing in the software requirements. They are basically known ‘hot spots. This information is used while making a risk assessment for planning the tests.

Root cause analysis is carried out to prevent defects and failures occurring continuously and perhaps to identify the cause of clusters and potential future clusters. 


5. Pesticide paradox

Repeating the same tests over and over again will eventually no longer be useful to find any new bugs. This is known as the ‘pesticide paradox’. To overcome this factor, the test cases need to be regularly reviewed and revised and new tests have to be added or updated to the system to potentially find more defects.

As the ‘hot spots’ for the bugs get cleaned up by the initial tests, the focus gets changed to the next level of risks. Thereby finding coding bugs to requirements and design documents for defects, and the process improvement to prevent defects in the product.


6. Testing is context-dependent

The testing approach is entirely based on the context of the domain or software developed. The domain is nothing but the line of business like Banking, Healthcare, Travel, Advertisement, Insurance, Security, Finance, etc.

Different types of software need to tested differently based on requirements, purpose, risk, techniques, functions, etc. For example, the Banking software is tested differently from an healthcare software. 


7. Absence of errors fallacy

Software built with minor defects can still become unusable if it does not satisfy the user’s needs and expectations. The testing performed against the wrong requirement is not useful even if the software is fully tested with all the major defects identified are fixed and ready for release.

The software would be considered as unusable by the client as it does not fulfill his expectations, thus finding and fixing the defects will not help in this case.