Software Testing Principles


It is always important to have the favorable result every time you do testing of your product, and also, it’s important to achieve the 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 principal which states 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 on a long time, the particular module will become the bug-free.
  1. Exhaustive Testing is 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 form completely and that’s an impossible task, so rather testing the complete form you should only focus on important parts or priorities instead checking all the combinations.
  1. Testing shows presence of defects
  • Like exhaustive testing is not possible, it’s always possible that you might miss the bugs in when you test the complete application.
  • Even you’ve large timeline and 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 defects possibility, but you can’t say the application is tested 100%.
  1. Absence of errors
  • Sometimes happens you don’t have 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 fulfills the user requirements even after finding the numerous bugs. So, Absence of error is the fallacy.
  1. Early Testing
  • It always demands to start the testing from the requirement gathering phase. Early testing benefits in many ways and can be overcome the tight deadlines.
  • The issues found in the requirement stages and development stages are easy resolves and cheaper. You have to start the find bugs from the first phase to SDLC. You can find more idea about the early testing in our previous articles as well.
  1. 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 their self from that pesticide. Then that pesticide is no more useful to remove insects.
  • Same thing happens with testing as well, if you doing the continuous testing on the same module for a long time with same cases and scenarios, it’s possible you can’t find any bugs on that module after sometimes. 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.
  1. Testing is context dependent
  • Testing is context dependent, you can understand what does it mean actually. You can’t test the 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 than testing an e-commerce site or testing a banking site. The software for the above sites are never going to be same and hence need different approaches for testing, so it’s always depending on the domain of product.
  • Facebook
  • Twitter
  • Google+
  • Linkedin
  • Pinterest

Leave a Comment

Your email address will not be published. Required fields are marked *

It is main inner container footer text