8

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?

Improve this question

7 Answers 7

Reset to default
3

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.

Improve this answer
5

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.

Improve this answer
3

I would suggest you add the new tests into your regression pack to ensure they are picked up in the future.

I assume you will run some form of regression prior to release, so between the two you have improved coverage and documentation going forward

Improve this answer
1

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.

Improve this answer
0

If you have a bug for each fix, then I would use those bugs to document how they each fix was tested and whether the issue was corrected or not. A formal test plan seems like overkill to me.

Improve this answer
0

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

Improve this answer
0

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
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.