Software Testing Principles

It is always important to have a favourable result every time you do testing of your product, and also, it’s important to achieve a bug-free product. Sometimes it’s an achievable task but sometimes testing is an infinite task, so when testing came to an infinite task? how to identify that the product is now bug-free at some level? For that testing have seven principles which state when one can start testing, move forward with it and when can stop the testing.

Following are the Seven Software Testing principles.

  1. Defect Clustering
    • Defect Clustering means that it always highly possible that a small number of modules have more defects, sometimes doing the alpha testing. By the time doing testing with each module, you can easily identify the issues from the module and for a long time, the particular module will become bug-free.
  2. Exhaustive Testing is an impossible task
    • Exhaustive testing is not possible, you can’t test every branch and every combination of the application completely. i.e. If your one form contains 10 input fields, with 3 combinations for all the input fields, you need require 310 possible combinations to test the form completely and that’s an impossible task, so rather than testing the complete form you should only focus on important parts or priorities instead checking all the combinations.
  3. Testing shows the presence of defects
    • Like exhaustive testing is not possible, it’s always possible that you might miss the bugs when you test the complete application.
    • Even you have a large timeline and the best resources and you test the application thoroughly, you’ll never be confident that the application doesn’t have any issue and tested 100%. You can only cut down the possibility of the defect, but you can’t say the application is tested 100%.
  4. Absence of errors
    • Sometimes happens you don’t have a complete requirement idea, but you do test the application completely. You be sure about the testing has been completed till 99% but what if it’s not usable to the user. The application is tested wrong since the start of the requirements, which states that you can’t be sure that your application fulfils the user requirements even after finding the numerous bugs. So, the Absence of error is a fallacy.
  5. Early Testing
    • It always demands to start the testing from the requirement gathering phase. Early testing benefits in many ways and can be overcome tight deadlines. The issues found in the requirement stages and development stages are easy to resolve and cheaper. You have to start the find bugs from the first phase to SDLC. You can find more idea about early testing in our previous articles as well.
  6. Pesticide Paradox
    • As the name suggests, if you’re using a pesticide to wipe out the insects it’s possible that in later time those insects can develop resistance to themself from that pesticide. Then that pesticide is no more useful to remove insects.
    • The same thing happens with testing as well, if you doing continuous testing on the same module for a long time with the same cases and scenarios, it’s possible you can’t find any bugs on that module after some time. That’s why it’s always recommended that to improve the test cases quality and change the test cases by time with changes in the product. Yet you can’t say the testing is 100% completed even after updating the test cases regularly.
  7. Testing is context-dependent
    • Testing is context-dependent, you can understand what does it mean actually. You can’t test one site with the same strategy as the other website. It always depends on what you’re testing.
    • For example, testing a shipping site is completely different from testing an e-commerce site or testing a banking site. The software for the above sites is never going to be the same and hence need different approaches for testing, so it’s always depending on the domain of the product.

Rahul R