Elementary Principle of Manual Testing

We all know that Software testing is most Challenging and Creative task at this time. In the world of software testing, To know about the principle of software testing is very important because it gives the basic understanding regarding how to perform testing. In other word, These principles are the base of a Manual testing process.

These principles are nothing but the first step to knowing the rules and laws to follow the testing process. It may be possible that by ignoring them cause the performance issue. Understanding it with theoretically and Examples give an excellent way for the tester to make testing efficient and Exhaustive.

Below are the Most Guided and Useful 7 Principle of Software Testing

1)  Software Testing shows presence of errors

In the process of software testing, we can’t say any product is defect free. When we make testing and found bugs and reported them but the possibility of  bugs are present is always high. It is possible that may be some defects are still present which not discovering during the process of testing. So base on this we can say that no product is 100% bug-free. To overcome this problem, must have to create test cases in such a manner that no error left in the product and it’s become errorless.

Example:  Suppose to in any product, we make effective testing and report the bugs but it is possible that this product may fail in the production environment.

2) Perform Early Testing


Whenever find any module to test, start testing as early as possible which give the best way to find bugs in early stage and it is possible to fix it as soon as possible. By doing early testing, the rise of bugs in the further functionality goes down and possible to deliver the product in given time period. This thing also helpful to reduce overall cost and increase software quality.

Example: When a developer creates sign up functionality, Don’t wait for another module, start testing on sign up functionality and correct this module as early as possible without error.

3) Pesticide paradox


For any tester, written test cases must be reviewed and revised Continuously because if they using the same test cases every time then it will create problem some time and it is also possible to not useful to explore new errors. Repeated bugs always create difficulty to test any software and not throw any new errors. So every tester has to improvise and modified test cases every time or project by projects.

Example: Suppose we have testing any application and given bugs for resolve and retest the resolved bug but if we use the same test cases then it creates problem here. We can not find out the result with accuracy and also no any new bugs we found for same. So to overcome this kind of problem, we have to implement new things in test cases.

4) Absence of errors fallacy

For any new build software, tester performs the testing and find the bugs and given for fix. After fixing those bugs, tester performs retesting but in the practical world, it’s not enough because developed software suppose to not fulfill the customer requirement or not perform exactly as the client want then problem rise here . If any new build software becomes unstable and not as per client need then discovering and fixing the errors or defects does not help.

5) Testing is dependent on Condition

Accepted that the tester testing the web application by it’s own means web method but when tester try to test any other like E-commerce or banking application with the same method then the way of testing here is wrong. Testing depends on the condition of on which software or application tester try to test. Only the appropriate testing method any tester can use instead of any random method. So appropriate knowledge of  testing the different application required.

6) Error Bundling

In the process of manual testing, it is possible that any tester can find the bundle of bugs from a single module. If any newly developed software tested by any tester and if he/she find the bug there then the possibility of other bugs are hidden there is higher and by doing depth testing he/she can identify the new bugs from a single module or single place.

Example: Suppose a new coming developer or fresher develop a single module then the possibility of bugs arise at single module is higher.

7) Full-scale testing is impossible

Testing on all possible input combination is not possible except for trivial cases. Depending on risk and priority any tester performs testing. It’s taking too much time and affect the cost and deadline of any project. In short, this principle tells that complete testing of whole software with accuracy is very difficult.

Above are the most key principle must be take in the notice for that person who are connected to the era of testing.


Want to work with us? We're hiring!