Forgetfulness plays a major role in everybody's life. In QA engineers life, forgetfulness can be an expensive thing.
Assume you are executing a test plan, and you have some more minor/average cases in your mind to be executed. You want to execute those cases after completion of the test plan, but you forgot to execute them, or you found a minor/average defect during the test plan execution itself. You planned to log that defect later as it is a minor/average defect. If this defect is reported by a customer then it is an expensive thing, and we always get a question like "Why QA missed it?".
We should report defect immediately whenever we find. We should not move to next case until we report all issues we found.
A few of the scenarios that came to my mind are listed below
A junior engineer wrote a test plan and sent for review to a senior engineer. Senior engineer forgot to review the test plan. Junior engineer reminded twice, but senior engineer forgot due to some other tasks. Junior engineer might have missed some important cases. Customers may report issues on those missed cases only.
We should review the test cases without fail.
You found an abnormal behaviour of product/project and you are not sure that it is a defect or not. You want to get confirmation from the developer or higher management. At that time, both are not available. You may forget to discuss it with them. Customer may find a defect in the same case.
We should clear our doubts with Dev or higher management. If they are not available we should drop a mail at least.
Assume you got a critical bug to verify for a major release which is planned 5 months later. That defect verification includes a lot of integration steps and also includes third party settings. You interacted with developers and searched in google and found all required steps. You set the environment and verified that defect. After 3 months, one customer asked for Hotfix release with this defect or our higher management planned for a service pack release with this defect. Now you need to verify this critical defect again which includes a lot of steps. You might have forgotten all these steps required. You need to interact with developers and search google again for the same steps. A lot of time will be wasted.
A final scenario where we should realise why documentation, not liked by most of us, is actually very important!
One of our team members verified this critical defect for the major release and resigned. Some other team member needs to spend the same amount of time.
The key to some best practices to be followed by QA is, to document all the steps required to verify a defect.
Assume you are executing a test plan, and you have some more minor/average cases in your mind to be executed. You want to execute those cases after completion of the test plan, but you forgot to execute them, or you found a minor/average defect during the test plan execution itself. You planned to log that defect later as it is a minor/average defect. If this defect is reported by a customer then it is an expensive thing, and we always get a question like "Why QA missed it?".
We should report defect immediately whenever we find. We should not move to next case until we report all issues we found.
A few of the scenarios that came to my mind are listed below
A junior engineer wrote a test plan and sent for review to a senior engineer. Senior engineer forgot to review the test plan. Junior engineer reminded twice, but senior engineer forgot due to some other tasks. Junior engineer might have missed some important cases. Customers may report issues on those missed cases only.
We should review the test cases without fail.
You found an abnormal behaviour of product/project and you are not sure that it is a defect or not. You want to get confirmation from the developer or higher management. At that time, both are not available. You may forget to discuss it with them. Customer may find a defect in the same case.
We should clear our doubts with Dev or higher management. If they are not available we should drop a mail at least.
Assume you got a critical bug to verify for a major release which is planned 5 months later. That defect verification includes a lot of integration steps and also includes third party settings. You interacted with developers and searched in google and found all required steps. You set the environment and verified that defect. After 3 months, one customer asked for Hotfix release with this defect or our higher management planned for a service pack release with this defect. Now you need to verify this critical defect again which includes a lot of steps. You might have forgotten all these steps required. You need to interact with developers and search google again for the same steps. A lot of time will be wasted.
A final scenario where we should realise why documentation, not liked by most of us, is actually very important!
One of our team members verified this critical defect for the major release and resigned. Some other team member needs to spend the same amount of time.
The key to some best practices to be followed by QA is, to document all the steps required to verify a defect.
