An organization spends enough money on testing to get good return on investment, customer satisfaction and ‘good will’. Hence the quality of testing directly impacts all these factors and here comes the pressure on the tester.
However, even after rigorous efforts if a bug is reported by the client post release of the tested product, it sets the tone of disappointment or pressure. And then the testers need to answer questions such as the following, “Why did we not find this bug?”, “Why was this usecase not tested?”, “Was our testing not sufficient enough to test the product?”, “What went amiss in the whole scenario?” and so on.
The quality of testing is always recognized from the quality of the use cases / test cases, and is tested either manually or automatically. Now, the next question in your mind would most likely be - Is exploratory testing not effective enough to bring out quality bugs? The answer is No, it is not so.
- It all depends on one’s own expertise in the domain, technology and various other factors- It’s not practical to have all the team members with expert knowledge.
- Most importantly, exploratory testing is not documented for regression. So a bug found in Sprint 3, solved and retested in Sprint 4, can get introduced in Sprint 8 and can go unnoticed. So in this case exploratory testing fails. Hence we have to get into some effective and efficient testing process that can be executed proactively and in a systematic way.
Usually when a requirement is provided to the tester, he/she intuitively thinks about the features and starts writing his/her own perceptions of the features as test cases. Now the test cases are all about his/her own knowledge level and thinking capacity. The reviewer (test lead or manager) of the test cases can add or correct a few test cases. Hence the derivative is very limited and it is quite possible that the tester has missed some aspects of the behavioral or usability related stuff.
If we have a proper testing life cycle, in which the tester should get involved from requirement gathering phase with the team. The team should always include BA/PM/Architect/developer and tester. So when all these people come together and discuss about the features, more views and suggestions arise based on their own expert level. These perceptions and suggestions are documented as references for the following:
- PMs/BA to write the functional specification.
- Developers to develop the feature.
- Tester to write their test cases.
You can see a significant change after you start following this systematic approach. The bugs introduced by the developer will drastically reduce and the tests are efficient enough to find bugs. But a scenario wherein there aren’t any bugs being reported from the client at all, post release is rare. However, the good part is that, comparatively, the count and severity of the bugs will be very low.
