I am new to QA and the single QA person on a team. I have a pile of bug fixes that the Product Owner would like to release. These fixes were coded by developers no longer with our company. When it comes to writing test plans, is it typical to write a test plan for testing a bug fix?
How do you prevent the bug from happening again? Most of the times the answer to this question is a test-case.
Now where does this test-case go? Into an existing test-plan or -suite, preferable automated.
- Fix the defect
- Test the fix (manual, exploratory or automated)
- Do a root-cause analyses
- Create a test-case/step/plan to prevent the root-cause from occurring again
- Execute all other tests
- Release fix
So yes, you do need to test bug-fixes, certainly when reported by clients, since it is possible different users report conflicting bugs. This could lead to a pingpong state between two similar issues, where with each release the bug returns for the other client.
But no, you should not create a full test-plan for each bug-fix, just add a test-case to an existing plan. If you do not have a test-plan or -suite it time to start one :)
You could do a small risk analyses and wonder what the risks are that it breaks again. Based on that decide how much testing effort your team should invest.
It depends on your company's preferred methodologies. You should keep a record of the test cases you performed to verify the fix, but most likely won't need anything as formal as a test plan for that.
Depending on how the fixes are implemented, especially when testing old code, you may want to execute other test plans of the product where the bugs were found in order to ensure the bugfixes do not create any more problems.
It depends on your company internal policy and how your team is organized.
Typically, if you are the only QA in your team, it will be your responsibility to plan and execute fixed bug testing.
Regardless if the developers are still with your company, it is still your company's job to ensure your software meets customers' expectations.
I would suggest:
Ideal practice is, We write test cases across specifications
When we observed any bug, If its having step similar to any test case then fine [No need to update test plan]
But If bug is having different test steps than any test case, we should add those step in test plan and that bug would be a one test case
In our software field, team keep changing frequently[many if the times, not all the time & everywhere] So keep practice of lesser dependency
Regardless of role, Keep updating your team for bugs observed and testing results to be on same page
I wouldn't add bug verification to the master test plan since this will pile up un-necessary test cases, after all once you verify a fix you don't need to check this particular case anymore.
But do consider-
- If applicable add the root cause of the bug to the plan
- Add some verification tests to the nearest release, but also keep in mind branching and merging policies since bugs might reappear in the future