Over the years ithas become a misconception among some that using the seven principles ofsoftware testing is not compulsory or required. But in fact, it is a necessity.
Most of these principles are implied sub-consciously by tester that have beenin the field for long. Even so, it best to check consciously for the presenceof these of principles to ensure good quality testing and effectiveness of theprogram! Let’s consider anexample. I make an application to deliver pizza. Principle 1: Testingshows presence of defects: This principle merely says thatin every software there is the presence of errors and having done testing doesnot say or mean that the software is now bug or error free. There may not be any technical errors but there my exist logicalerrors.A person using my pizza applicationmy be allowed to order 0 pizzas, which does not make any sense. This is anlogical error.
Principle2: Exhaustive testing is impossible:The whole point of conducting testing on a software application/ web-application is to uncover the errors which were not spotted earlier. Therefore,the best testers would obviously try to cover every inch of the program, or inother words conduct extensive testing. In reality, it is extremely difficult toperform such of a kind fully comprehensive study of the program. Thus,’exhaustive testing is impossible”. Principle3: Early testing:Testing should begin in the very initial stages of the development of thesoftware. Defects can be found even in the documentation, not only inprogramming or functionality. Moreover, defects found at these stages can befixed in lower the cost and saves time. When we start with the documentation of the pizza applicationwe begin with the requirements and planning the design of the user interfaceand structure of the program.
It is at this stage that I may realize thereshould be limit to the number of pizzas ordered. Or that a pizza should have amaximum number of toppings. These errors would be caught before beginning toprogram and help the developer implement the changes beforehand instead ofchanging it later.
Principle4: Defect clustering: The Pareto principlestates that “approximately 80% of the problems are found in 20% of themodules”. This means that a bunch of errors are usually found in some particularcluster of the program. Sometimes after fixing errors, new errors are generatedin that section and theses to have to be tested for. Principle5: Pesticide paradox: After testing thesystem a few times, we may not be able to find new bugs in the program usingthe same old test cases over and over again, which is of course a good thing.
But we have to make sure that new types of errors have not been generated,especially after the older ones have been fixed. Thus, we perform what iscalled as regression testing. Principle6: Testing is context dependent: For every which contenttype, there exist different methods / approaches and techniques for testing.Some software’s maybe be tested using tools. Mobile devices and webapplications shall use different tools and approaches.The mobileapplication for the ordering pizza and desktop website for the same will be testedusing different methods. Principle7: Absence–of–errors fallacy: For the customer, the mostdevastative defects are those that do not fulfil their requirement. Hence itsaid that “All tests should betraceable to customer requirements “.
A software without any errors (veryunlikely!) may not be the best made if it does not do what the customer hasrequested for.In the application I have made,an user is able to order pizza and the pizza is even delivered successfully.One would say that the application works very well. Although the error that isuncovered later is that the application has been making an error in calculatingthe bill!