How To Test In A High Developer-To-Tester Ratio
A few times throughout my career I’ve found myself working in an environment where there is a high developer-to-tester ratio.
I’ve been the only tester with 4 developers. I have also been the only tester with 11 developers.
Interestingly enough, I was equally busy in both environments because the 11 developers often had blockers since we had external dependencies. Meanwhile in the environment with 4 developers, things were set up so well that we were constantly shipping to Prod.
Here I would like to share what I have learned when testing in a high developer-to-tester ratio setup.
Quality Is A Team Effort
I am not responsible for the quality of the product.
We all are.
Good practices like code reviews are a great habit for your team.
I’ve also found holding testing discussions really helps here.
Here is my article on How to Actually Prevent Bugs.
Manage Expectations
First and foremost, I ask developers to make sure the main part/happy flow works on their machine. At the very least they should do this. They are, of course, welcome to run additional tests.
On one of my previous projects, a developer kept assigning me PRs when the whole point of the PR in the first place, didn’t work. The extra back and forth wasted my time and caused me to fall behind.
A not-so-nice way of putting this is:
Don’t waste my time with stuff that you haven’t even checked on your own machine.
Fortunately, most developers I work with take pride in their work. Often I also like hearing a “challenge” (to see if I can find any problems) in their tone when they assign me their PRs.
Since there is only one of you and quite a few developers you might not always be able to test new features/builds/pull requests straight away.
In the past i have done this by:
- Telling the team that when I start testing something, I will let them know
- When I am done, will let them know as well (regardless of whether or not I found any issues)
- If they don’t hear anything from me, it’s because I haven’t tested it
- Thing can fall between the cracks, if they don’t hear from me, they may need to follow-up
Clear Communication
Clear communication is even more important here. I try to avoid unnecessary back and forth, therefore I ask developers to provide me with:
- The link to the build/details on how to access the build
- Any Jira link or ID (or whatever tool you use) that is associated with what you are testing
- Anything else I should know
As part of our team’s Way of Working, we also would have agreed on how this information would be communicated. Often it would be online or Slack. (I tend to steer clear of relying solely on tagging people in a tool like Jira because:
- I’ve had problems in the past with notifications
- It can be overwhelming with lots of notifications and you can get lost in what actually needs to be done vs what you’re just being updated on
Be Organised
Working in such environments forced me to get my act together and make sure I am organised.
To do this, I put systems in place:
- I use a notebook to write down what I plan to do at the start of the day, and then update it when we have daily standups and when I get approached by others to do more work.
- At the end of the day, I create a to-do list of what I’ll do tomorrow.
- At the start of each day I look at my calendar to see where my gaps between meetings are and plan tasks accordingly. If I have a small PR to test, I may test that first, in lieu of a bigger PR I was asked to test earlier, because the gap between meetings is too small for the big PR
- If I start a task, I finish it and not switch between multiple tasks unless an emergency comes up.
- I utilise Do Not Disturb if I’m struggling to focus on my testing, if necessary I was close Slack altogether to not tempt myself by being nosey in the channels
Ask For Help When Needed
It’s important to know when to ask for help
- If I find that I have too many testing tasks in the backlog, I let the team know, then the developers, scrummaster, product owner or business analyst may help with testing
- If there are testers in other teams, and they have capacity, they may also help as well
- I find it’s most important to communicate that things are falling a bit behind - instead of just staying quiet. All of the team leads I have worked with, have appreciated early communication in this regard.
📹 If you enjoyed reading this post, check out my YouTube channel and subscribe.
I post videos that can help you with your software testing career.