Multiple people reviewing a Pull Request

Question

This is a question around job satisfaction, rather than anything technical.

Some background: I'm a manual tester for a web app and my main job is to test new changes and features through PRs. By the time these feature branches hit the PR stage, they've gone through unit and E2E tests, and I'm there to give it the final test through the UI in various browsers/cross-platform. The change can be anything from a tiny one-line code change (like updating a tooltip or changing the colour of a button), to a whole new feature with many functional changes.

In addition to me as a tester being tagged in PRs, so is obviously another developer to review the code. Then additionally, one to two UX designers are also tagged, and occasionally one of the Product Managers. The designers and PM are there to request possible final changes before the feature is merged and released to live.

Normally this works well and I enjoy testing everything thrown my way. But quite frequently I find myself getting a bit frustrated about the amount of people tagged, because – this will probably sound selfish – if I don't "get to" the new and shiny fast enough, the designers and/or PMs have already looked at the changes and raised many visual (and functional) bugs they've come across. So when I finally get to the PR, there's sometimes nothing more to raise.

Now, obviously the quality of the product comes first and it doesn't matter how and who raised the issues, as long as they were raised. I understand that, and that's why I fully accept the situation. But simultaneously, I can't help myself for feeling disappointed whenever I start testing a PR and all the bugs I come across have already been raised.

Why do I like my role as a tester? Because I can be part of assuring quality for our product and keeping our users happy. But in addition to that, I also love it because I'm allowed to play detective and catch functional bugs and find visual inconsistencies, and figure out how to recreate them. It's fun and satisfying. It's this last part that quite frequently doesn't get fulfilled due to the amount of people tagged in the PR. Even more now that we've hired another UX designer.

Does this sound familiar to anyone? In the end, I realise there's not much I can "do" about it – obviously anyone needs to report a bug if they find it, and it's for the good of the product. Changing our process so that the designers won't be tagged until I've had a chance to test it, doesn't sound very effective either, and I feel pretty childish even thinking about it. The more time they have to suggest changes, the better, right? I think it's just down to me to change my attitude and try not to get frustrated? If anyone who's been in the same situation has any tips on how to do that, I'd be grateful. I haven't brought these thoughts up with my manager yet, because I feel I will come across as immature, even though he always does ask me to voice whatever's on my mind even if it's nothing we can change.

Answer 1

I feel you are blessed to have such a team. I have worked with teams with ratio 1 QA to 10 developers and handled multiple projects at a time. In this case, I used to get bombarded with User stories from developers, with least bit of testing from their side. This environment is highly toxic for a human being because:

1. No time for a break
2. Bombarded with user stories and features to test
3. Management starts to feel QA as a bottleneck for the process as too much stuff in pending state for testing.
4. This will make you feel less valued and hate your role.
5. Work on multiple use cases simultaneously and thus cannot concentrate on anything specifically.
6. Multi-tasking or switching context so rapidly creates lots of stress
7. Affecting personal life and confidence
8. Get least appreciated because everyone things being QA is easy
9. Raising simple issues as you mentioned actually makes our work look easy,
10. Quality responsibility is moved to only QA and it becomes too much stressful.

So you are blessed to have a completely agile aware team, that takes quality as a team responsibility. Benefits of working in such a team

1. Concentrate more on other skills like test automation and DevOps.
2. Try to find more tough and interesting use cases that can break the system, than depending on simple UI bugs.
3. See how developers review the code and learn from it.
4. Analyse source code and find ways to break the code logic (white-box approach)
5. Talk to customers, UX designers etc and give suggestions to improve there design. Because sometimes even UX designers are neglected in the team, they like to get genuine feedback.
6. Analyse the issues raised by team members and find where is defect clustering is happening, which feature are they more interested in.
7. Raise more severe and more interesting bugs that they missed on those features.
8. Be excited to find 5 severe challenging bugs , then 100 easy ones

Answer 2

This sounds like a dream tester job to me, we can perhaps swap jobs if you want, you'd get many of these in my current position:

• absolutely no unit tests, because devs are always running out of time with new featurs and projects, project managers do not even consider the option of little more time for unit tests
• there was no tester in the company before me joining, so some don't even know what a tester does
• no other tester in the company but me
• no other people who would even remotely consider deliberately looking at some PRs in order to find what's wrong
• multiple (4 - 6) projects at the same time, all of them equally important of course
• high dev turnover, they're a few "core" devs, the rest stays about 8 months and they hand in their notice, so there're always new people who are new to the projects

I do think your situation is one you want to be in. As a tester, you should not try to be the only one who finds bugs, or the only one who says something is ok, or the only one who says when we are ready to go live. This is a team work and that has its reason, it simply minimizes the risk of one person overlooking something.

Perhaps you can try to become a sort of a mentor to others. I believe you know more testing techniques, you know more about where some bugs might be found, and so you can share this knowledge with others. It might be something you become interested in because then others would find more bugs thanks to you. The project(s) would surely benefit as well.

Answer 3

I would suggest you to consider this situation as a good starting point for developing your leadership and management skills. I was even thinking of starting my answer with "Welcome to QA Management world!" because what you talk about is really a situation (not quite frequent but nevertheless) when you have a change and a lot of free resources so you have to solve the problem of breaking down all the job so that maximum parallelization is achieved.

You can start taking synchronization role, break the app by the responsibility areas, or just watch your designers and PMs do not interfere with each other.