Joise is a functional tester and has been ensuring asset management and wealth management software quality for years. He has also been a Tester Work freelance tester for over 6 months now and he enjoys writing about his experience as a tester.
In every software development area, we have a product team who handles client and their requirements. They do take care of the required writing by analyzing the client’s requirements. I keep on saying that requirement proposals should be the bible of a tester. I strictly follow the requirement proposal document or the FRD (functional requirement document) for preparing or designing my test scenarios. I read requirement documents prepared by the product owner more than a few times and that will depend on the complexity of development in my hand. I do not allow or permit deviations found during the testing process from what the functional requirement document says about a feature. We should have written communication from the client or the product owner about the deviation that happened during the development, otherwise, it is a defect from the tester’s point of view.
I am taking you to the relevance of a functional requirement document here, a test plan scenario should cover each line from the requirement document. Read every corner of a functional requirement to understand the actual client requirement. A tester should have a sharp picture and knowledge about the acceptance criteria of development always to achieve quality deliverables. Inside every test plan document, we have the key steps to deliver bug-free software. That is why I always write test scenarios corresponding to each line from a functional requirement document. It will ensure that we do not miss any feature or requirement that clients may want to have in their system or the software.
Because we do not have the chance of retakes once the product is completed and released to the client’s functional area. A small failure or issue will cause high-level dissatisfaction in the client’s mind. But I cannot stop you here, you should always prepare test plans based on the experience that you may have with the software and related modules. A tester should be careful about the functionalities that may get impacted by this development. Hence a test plan should include the inter-related scenarios as well.
A test plan document will become effective once it covers all relevant scenarios. Each step that you write in the test plan will bring a possibility of defects. A count on defects does not indicate the quality of software, but it can prove the amount of work contributed by developers and testers. Wherever you see some blockers, stop there and have a coffee with your product owner with the same. And develop and improve your test plan during the testing process to keep it aligned with the testing methodology. At each stage of the testing process, we have a chance to create more test plans and scenarios based on the test results. Nobody will stop you if you bring more test cases into the picture during the testing process.
Simple steps and descriptions in the test plan document are a must thing as they should be readable and self-explanatory to a third person. A tester will always create possibilities for new enhancements by creating defects. So, keep that in mind always, you are an integral part of the software development. Enjoy testing, creating defects, and delivering developments with pride. My fingers are crossed, Thank you.
