We’ve noticed that a significant amount of QA Teams in our user-base have a high developer-to-tester ratio, sometimes hitting 10 developers for every 1 tester. Although this ratio depends on the organization and it’s internal processes, with 10 Developers for every 1 Tester, we can safely say that this gap is far from optimal for most teams.
What are the signs of an Overworked QA Team?
Testers are often overworked and overlooked.
1. Delayed Deployments
Ever delay a release because of testing? With ever tightening release deadlines, many teams can’t test everything before the deadline (especially when developers are making late changes), so they either must sacrifice time-to-market or risk releasing untested code into production.
2. Declining Quality of Product
Being overworked or understaffed both have the same outcome. If testers don’t have the bandwidth or resources to properly perform their role, bugs start to leak into production which leads to frequent hot fixes and an unsatisfactory user base.
3. Test Automation is not completed during the iteration
If QA Teams are constantly performing hot fixes and chasing flaky tests, they can’t keep up with writing automation tests.
Writing in a favorite automation test framework to cover app functionality is a highlight for many testers – and one of the very rewarding parts of their job that pays dividends down the road for both them and the team.
4. QA Team Working Long Hours
Timelines extend with short-staffed QA Teams.
For example, if full regression testing for a release is needed in a certain period, a short-staffed QA team will frequently ask for the release date to be pushed. There’s simply too much ground to cover and not enough testers to hit those deadlines during standard business hours. If that deadline is not pushed, they will either need to work longer hours or over the weekend to meet the deadline – or else risk merging poor quality code into production in a time crunch.
5. More Tasks in Backlog
Tasks begin to compile in the backlog when QA teams suffer from a heavy workload. What hurts the team most of all, automation testing takes a backseat which makes things worse in terms of release cycles.
6. High Turnover
Another tester quit? One of the main causes is that testers may not feel like they are doing meaningful work and are in a constant state of catch-up.
Pro-active work for testers is undoubtedly more rewarding than constantly putting out fires. If testers had more bandwidth to perform the tasks they find satisfactory, they’d more likely find the job rewarding.
How to increase output and QA Team job satisfaction
1. Stop Delayed Releases from Happening
At Appsurify, we too experienced delayed releases at end of sprints because our QA Team didn’t feel confident about the build. We found this happened pretty regularly as we were trying to keep to a weekly sprint/release cadence. Once we released our risk based testing tool, TestBrain, we’ve leveraged it to help hit release deadlines faster by automating which areas to test after each developer commit instead of needlessly testing everything.
Even when a developer makes a late change, we’re able to automatically pinpoint the area of change – and just test in that impacted area, either via automation or manual testing.
Outcome, we’re now able to hit our deadlines earlier by removing unnecessary testing. Because why run the full automation test-suite when only a fraction of tests have been impacted by recent developer changes.
Risk based testing has translated into multiple value drivers for our organization to help hit sprint deadlines earlier and ease the workload on our testers:
- Just test in the changed areas.
- Reduce CI Pipeline build times by 80%.
- Get feedback to the developers 10x faster to fix bugs while they are still on the relevant task.
- Reduce context switching.
- Give Testers a tool which automates where to test after each change.
- Make Testers feel like Rockstars!
We’ve freed up considerable time for our QA Team by providing them a tool that automates the most time-consuming tasks of their job and have accelerated our release schedules as a result.
2. Increase Quality of Product
As stated, bugs slip into production when QA Teams are overworked or understaffed.
When we gave our testers our tool to leverage, we were able to boost each member’s output by 10x. We eliminated their time-consuming process of chasing Flaky Tests and cut the time it takes to complete testing by over 90%.
Now each Test Member is above water testing only in the changed areas and getting relevant and timely feedback to developers during the most important time of the day – in real time.
Outcome, testers and developers are catching bugs as they are made and have achieved a true shift left strategy where the feedback loop between the two teams is as tight as a knot.
3. Test Automation is back as a Priority
When test script creation takes a backseat, it can create a technical debt which can snowball very quickly if not handled properly.
After the introducing our time-saving tool, our QA Team’s time freed up considerably to facilitate healthy proactive work – such as focusing on creating automated test-scripts. Testers are now well above water and adding to code coverage.
4. No more overtime for development and QA Team:
We, like many organizations we’ve spoken to, also experienced several instances where our team needed to work late in order to meet a release deadline. One time, maybe two times is acceptable. When late hours becomes a regular, that’s when problems can occur.
Fortunately, TestBrain has helped our development and QA team from avoiding to work past normal hours. Since development now gets test results back into their hands on a per commit basis, they are able to find/fix defects as they create them. So when time comes to release, the testing of the code has been done in tandem – and we can deploy on time and with confidence.
5. Tasks are handled on time
Our CI pipeline builds were taking too long to complete (over 1-hour) because of our automation test-suite bloat. As a consequence of waiting that hour, developers jumped around to different tasks. At first glance, multi-tasking seemed like a good idea – have them work on something else while waiting on their previous test-results. But what we quickly realized, context-switching actually lowers productivity and hurts quality of product. Developers were more likely to introduce new defects the more they jumped around.
As we rolled out TestBrain, our CI Pipeline build time went from 60 minutes to now under 4 minutes. Developers now get test-results before they even consider moving onto another task. The timeliness and relevancy of test-results has greatly enhanced the quality of our product and the ability for developers to confidently complete tasks on time.
Our shift left strategy (bringing testing closer to development) has been accomplished because developers no longer wait for test results after each commit. They know where to fix any issues immediately after any change.
6. Lowered QA Team Turnover
We experience turnover just like any company out there. But what we have been able to eliminate as a cause for turnover is the constant feeling of ‘catchup’ for our testers and developers. We’ve freed up their time to focus on the rewarding part of their jobs, and our team and culture has steadily improved with it.