There is sometimes the following situation happens to me: I report a bug. Then the dev fixes it. Then I re-test and discover a new one (I think it's not a new bug introduced, it's just me that missed it since last time). Then dev fixes it. Then while re-testing, I find another bug, again. I feel really bad for doing this, that I just don't find all the bugs at the same time.
Will the developer hate me for that?
The situation you describe happens all the time in many different contexts. It's not that unique as you might think.
I feel really bad for doing this, that I just don't find all the bugs at the same time.
There is no concept of "finding all the bugs" in testing. You only find all the bugs you are able to find and notice. Sometimes you notice different things at different times, that's how humans work. Nothing to feel bad about.
Generally speaking, I find it better if you can find more problems at one time and share that feedback with developers at one time. Although, I'd not downplay the importance of your particular context - perhaps devs at your place find this actually worse. Go ask them if in doubt. There's nothing better than a discussion about how they would like to work with you.
If they actually tell you they'd like to have more bugs reported at one time, you can train yourself to do that. I think it's mostly a habit of how you look for problems and report them. If you find a bug, take a note and continue looking for more. At the end of your test session, you can report all these problems you found.
The general process of reporting a bug and then retesting that bug, perhaps including additional regression testing around the changes, and reporting any new issues is normal.
However, what doesn't seem normal is it sounds like you're stopping testing after finding a bug and waiting for that bug to be fixed. There are cases where the existence of an issue in part of the system can put a hold on certain types of tests - some tests may be blocked by the defect, others would have a high likelihood of being impacted by the bug or its fix. However, unless the system is very, very narrow in scope, there are probably other things to test and you can report issues on those for review and triage while the developers are fixing other bugs.
It also doesn't strike me as normal if rework like bug fixes are being rejected often. The developer has some level of responsibility to check their own work before it gets tested, especially if there's a handoff to a different tester. I'd definitely want to dig into why so many bugs are being found so close together and what can be done to solve that problem.
I very much understand your situation and concern and I feel bad too, sometimes. But this is our job and responsibility. In this case your communication and Bug's severity and priority helps alot. Suppose you are finding bugs, but you can defend it by saying that its not urgent or crucial we can move to next sprint etc. Also you need to communicate in a way that developer should not feel offended.
During the testing cycle, the majority of the QA engineers find themselves in the described situation. Usually, a software testing services company has well-defined processes to reduce the multiple Dev-QA cycles for a feature.
To improvise this situation, we should increase the test coverage & take more time in the initial phase and try to identify the defects from the related areas at once. After that, we should circle it back to the dev team with multiple defects.
Although it will increase the testing time, this will aid in shortening the QA-Dev cycle.
If the bugs are in the same section of code / ui widget then it will be easier for the developer if you present all the issues in one go.
If the bugs are on separate components, say unrelated screens then separate reports will be generally preferred as the fix will be for that specific ticket.
Generally, try to find all the bugs you can during a QA pass. Group them as you see fit. separate different functionality areas with different tickets
