Monday, October 19, 2020

Basic principles in software testing

Sometimes, when testing a large number of new features, testers forget even about the most important principles in testing and thereby make many strategic and behavioral mistakes in software testing.

In this article, I will remind you of the well-known and basic principles that should not be forgotten when testing any application or new feature.




Basic principles in software testing

Of the many principles that every tester who is testing software has probably singled out for himself, there are the main ones in the opinion of the testers community, which I would like to highlight:

1) Exhaustive testing is impossible by any of the testers . 

I think that everyone understands that it is simply impossible to test all possible cases and combinations, of course, if this is not a trivial case.

All cases simply cannot be included in the test suite, as it would take us a very long time and in the end it would not cost us such an effort. If each tester sits down and thinks over all the scenarios carefully and if you give this feature for testing to another tester, then he usually finds a bunch of possible scenarios and cases that can be included. therefore in top software testing company in India , it is customary to analyze a product or a new feature and then focus testing efforts on more risky and priority cases and areas of our product.

2) Accumulation of bugs... 

If you take a product and break it down into modules, then during the testing process you will notice that the main part of the bugs lies in one or several product modules, therefore, the effect of the accumulation of bugs can be noted. 

As a rule, this can be observed in completely different products. In order to effectively test our product, you should distribute your testing efforts according to the real density of bugs in the product modules, but if we are testing for the first time, then in proportion to the expected density. Over time, the bugs accumulation trend can change from module to module. This should be monitored and effort redistributed in further testing.

3) Effectiveness of early testing . 

It is very important to start testing as early as possible and to anticipate possible mistakes that the developer can make.

Before developing and testing this or that product, you should find out all the specifics, possible conflicts in the specification, the impossibility of a new feature to interact with another module, make sure that the tester, developer and product owner equally correctly understand how this will be implemented. Remember, the earlier bugs are found, the cheaper it is to fix them.

4) the pesticide paradox... 

If, after writing test cases, we run them many times, then ultimately these cases will not help us find new bugs. Therefore, there is a practice in testing when they revise and modernize test cases in order to catch some new bugs. 

Test cases can become more complex, be versatile so as to cover all components, modules of our product, which in turn will help us find more interesting and new bugs.

5) Testing depends on our product . 

There are many programs, products, and each of them should be approached individually in terms of testing. In some, more effort in testing is needed for security testing, in some for usability. Therefore, you should not row all products under the same brush and test according to any one template.

6) Testing shows the presence of bugs in the product, but not their absence . 

Many people think that if the new functionality has passed the testing stage, then that's it - there are no more bugs. Therein lies the erroneous judgment. Testing only reduces the likelihood of bugs in the product. Therefore, during the testing process, many bugs can be missed and this does not mean that if the product has been tested, then now this product is 100% working correctly.

7) The product is well tested and there seem to be no obvious bugs, then this is a good product... 

Sometimes when testing and looking for functional bugs, we forget to look from the other side and ask if the user needs it. If this feature does not meet the user's expectations and needs, then no matter how high-quality our product is, this is not so important.