You encounter a bug during a test. Do you continue the test (assuming the bug isn’t blocking this and you weren’t at the end of the test yet) or do you change the status of the test to failed directly?
As soon as bug is fixed. Do you only test the bugfix or do you rerun the complete test (you must do this when you changed the test directly to failed)?
Do I understand correctly answer to above questions are related to/depends on the test granularity?
I’m asking this because we would like to further improve our process. I tried searching the internet for an answer but couldn’t find anything helpful.
It depends on
I do it in all variations depending on the topic I test. Therefore I suggest do not regulate this explicitly in the process but to leave it up to the people.
IMO the status is less relevant but to talk to people.
Some of my examples:
I have a list/table with in the issue where I note all my findings. I really seldom stop at the first bug, but try to go on as far as I can. Then:
1.1 Either: I’m done within one test session and hand over all findings at once.
1.2. Or: I’m not done with the actual test session, but because of the amount I handover the first bugs to the developer so he can start fixing while in I continue.
I have a list of tests outside of our issue tracker e.g. in Confluence. For all bugs I create dedicated bug issues which I link on that page.
The test of bug fixes depends on the concrete function.
Is it quite isolated, we don’t expect much side effects? The I just test that .
Had the developer to change much of the code “just to fix this”? I test more things again.
Talk to your developers and project manager about the implementation and the risks.
You can’t always know from the outside.
One more thing about bugs:
Often before I set a issue to Failed I ask developers to help me investigating the bug. To find more out about its cause and consequences.
Changing the state of the issue is just a formal step.
“Individuals and interactions over processes and tools”