I would suggest for the tester to become more of a testing coach than a tester. At the ratio of 10 to 1, and you have the idea that the tester needs to do all testing, most likely you have one of two scenarios. The testing is super shallow and could easily been done by anyone. Or you are the single greatest bottleneck in the team, preventing a lot production value. Neither is fun for the tester.
So what is a testing coach? The main idea is that you instead of focus on doing the testing, teach the entire team to be part of the testing. A few tools you can use to get there.
- Shake and Bake. No idea why this was the chosen name but the concept is. Sit with the developer at their computer, before they push their changes and test with them. Excellent opportunity to find things early, address them right away and share your expertise and reasoning so they can replicate that for the next feature.
- Testing Tours. Great tool to help people look at their application from different angles to help with a larger scope for little effort. Is also feature agnostic so you do not have to do repeat work with people.
- Test Fest. If you for some reason have to “test everything in the end”. Buy some snacks, create two leaderboards. One for issues found another for issues fixed. Buy two prizes and gather everyone in team and test the product. The member in the team that found most things get one prize, the one that fixed most things get the other.
- Pairing. Pair with the developers for a power pair where the tester provide the expertise of “What should we test” and the developer implement it in unit tests and integrations tests. This way the testers (or the developer) can go and do a few one time tests for what is not already covered in unit tests. And the tester will know what extra scope they need to add.
Also remove the notion of Development Done and Testing Done and introduce the idea of Feature Done (testing included). Which also removes the idea of Developer and Tester. You are both developers, as in you develop a product. If you do not have it introduce the Definition of Ready and the Definition of Done. If you already have them make sure something is not Done until it is actually ready to give to the customer.
Another transition I suggest that you think about is what is presented in the Pretotyping manifest. The “Build the right it, before you build it right”. There are a lot of things one member can do in a team during the inception of a feature to dramatically reduce the production time, and the likelihood of errors, which is more akin to “testing the idea” rather than testing the product.