The top management of the organization spends huge money on testing to get good return on investment, customer satisfaction and “good will”. Hence the quality of testing directly impacts all these factors.
A "Feel of Disappointment" or "Feel of Pressure" is seen when a bug is reported by the customers post release of your product. And every time a bug comes from the field, you are prone answer some annoying questions like,
"WHY IS THIS USECASE NOT TESTED?"
“ARE OUR TESTS NOT SUFFICIENT?”
The quality of testing takes its root from the quality of the usecases / testcases, documented and tested either manually or automatically. Now, you will have a question in your mind that the exploratory/intuitive testing is effective enough to bring out quality bugs. Yes, it has a lot. But the cons is,
- 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 the expert knowledge.
- Most importantly, exploratory tests are 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.
Hence we have to get into some systematic approach to have effective and efficient tests that can be executed regressively. And yes, this is possible.
Usually when a requirement is provided to the test engineer, he/she intuitively thinks about the feature and start writing his 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 of the test cases can add or correct a few test cases. Hence the derivative is very limited and could be possible that the tester has missed some aspects of the behavioral or usability related stuffs.
Here the change what is introduced is that, the collection of the use cases is actually done by a group and not by the tester alone. The group should always include the Subject Matter Expert, Product manager, Product Architect, Senior Developers, Developers, Automation tester and Manual Testers of that product.
So when all these people come together and discuss about the feature, more perceptions comes out based on their own expert level. These perceptions are documented, so that this becomes as the references for
- PMs to write the functional specification.
- Developers to develop the feature.
- Tester to write their test cases.
You can notice one change after starting to follow this setup. The bugs introduced by the developer will drastically reduce and the tests are very efficient enough to find bugs. But I don’t promise that there will not be any bugs coming from the customer post release. But comparatively, the count and severity of the bugs will be very low.
I’ll be happy to hear your words.
Add a Comment