The-lone-tester-Amy-Phillips-testing-circusBeing the sole tester, whether forming the beginning or the end of a test team, creates huge opportunities which are tempered by some hefty responsibilities.
If you’re the first tester hire in the company you may find yourself responsible for creating effective test processes across multiple teams. Perhaps you’re responsible for testing multiple products, or have been asked to lead the hiring of new team members. A lone tester as a result of team shrinkage could face all of these challenges plus additional pressures to take on testing work that was previously carried out by others.
In these cases it can be easy to say that the company doesn’t value testing. This may be true but I think more often it isn’t. After all you work there, so somebody must recognise the need to employ testers. Maybe the budget to hire more testers doesn’t exist or the person in charge believes there is more value in treating testing as a team activity rather than having a large, isolated test team.

You certainly face a lot of hard work but as a lone tester you face unlimited possibilities and have the perfect opportunity to create a test process that benefits you. If you’ve inherited an existing test process, or existing tests then you have a good foundation to build upon. With a bit of luck your team, and your boss, already appreciate the value a tester can bring to the product. Appreciate this foundation but don’t become complacent, even the best process in the world will require some tweaking if the team size reduces.

A lack of time, and possibly resources will be your obvious challenges but try to become creative in your approach, and persistent in your efforts. Continually identify ways you can improve your own testing and the quality of the product. Make sure you are always focused on the place where you can have the most impact at this time. Maybe this will be testing the end product or possibly getting involved in the requirements gathering. Either way know your own skills and speak up when you identify ways you might be able to help out.

I once heard a story about a lone tester who had been hired by a company that recognised it had a problem with bugs in production. Unfortunately this tester wasn’t being brought in to try and help prevent these bugs, or indeed to even try to find these bugs before they went to production. No, this tester was expected to sit at a desk and test their way through the entire system, raising bugs in the bug tracking system. The team hoped that the whole system would be tested in a week, the following week the testing would start all over again. Meanwhile the developers would continue with their normal development and release processes; they’d continue to work in the exact same way they always had done despite everyone agreeing that they were releasing too many bugs. In an ideal world the testing would have happened before the code was released to production. Or maybe the tester would’ve been involved earlier in the process to try and prevent some of the bugs from occurring. Maybe the developers could do with learning a bit more about producing and testing quality code. When you end up working in an environment like this you’re in danger of morphing from a lone tester into a lonely tester.

A more positive lone testing role requires you to recognise that you can’t operate a regular testing process alone. Unless you wish to become the very unpopular gatekeeper holding back a flow of releases, you need to think of ways to reduce your involvement in some of the testing activities. I spent many months being the gatekeeper who dealt with an endless stream of developers wanting to release code. Code that I didn’t have the capacity to test because I was too busy trying to help people write good code. Eventually I realised that being a lone tester was very different from leading, or working in a test team.

James Bach talks about the lone tester as being an “omega tester”. I like the thought that an Omega tester has a choice about whether they act as the harmful Omega 6, using testing as a blockade within the team, or as helpful Omega 3, lubricating the way to better software development. When time is limited, and your company has actively taken the decision not to expand the test team, you need to become ruthless in your assessment of testing activities to make sure you apply your time in the most productive way.

Testing is a skilled activity and one that relies on you being able to draw on past experiences. That doesn’t mean that anyone can’t test. Testers are not born into the profession, instead they dedicate time to studying and practising it. I decided that my development team deserved to be given the chance to become testers. I know they will always be developers foremost but that doesn’t mean they can’t learn enough testing skills to assist me in testing the system.

If you talk to a good tester the chances are that you will find they consider testing to be a fun activity. I know I enjoy a good bug hunt, and my recent experiences with Weekend Testing seem to prove that others feel the same. Unfortunately testing seems to have earned itself a reputation for being repetitive and boring. Great developers recognise that testing is valuable, and often want to get involved to make sure their work is right, but very few are going to look forward to testing. This is the first problem to tackle, through presentations, workshops, and hands on testing you can teach developers test techniques as well as the thrill of the hunt.

Requiring developers to test their work is an old and often controversial topic. However as well as the benefits of having more people to help with the actual task of testing, albeit to a junior tester level, I find testing to be a powerful learning tool. Exploratory testing is a great way to see a system as a whole, you’re forced to experiment and observe. As you become more familiar with the system you can start to understand the troublesome spots. Hopefully by improving the knowledge developers have about the system, and its users, you can help them to avoid bugs.

Making testing a key part of a fast and flexible development and release process helps make testing seem relevant to the development team. No one likes to screw up but many development processes seem to be designed to wrap developers in cotton wool. Make them take responsibility for the code they are releasing. All production bugs should go back to the team that released them, regardless of how important the work that team is doing. This is a simple way to make developers care about the quality of their code and yet one that so many teams seem to want to avoid.

Software development is about building a quality product. Testing is part of the process needed but it shouldn’t be raised onto a pedestal. As a lone tester you hold the insight needed to integrate testing into the process. You have the knowledge required to design and execute complex and revealing tests. You also possess the expertise to design a test process that has a bunch of junior testers at the heart of it, and you are the best person to give these junior testers a solid education in testing.

A tester should be completely focused on assisting the delivery of a quality product. If this means you need to spend all of your time researching who your users are then this is what you should be doing. Be realistic about your time and availability and use your skills to make sure testing has the biggest impact it possibly can for your project.

https://i0.wp.com/www.testingcircus.com/wp-content/uploads/The-lone-tester-Amy-Phillips-testing-circus.png?fit=1024%2C391&ssl=1https://i0.wp.com/www.testingcircus.com/wp-content/uploads/The-lone-tester-Amy-Phillips-testing-circus.png?resize=150%2C150&ssl=1Amy PhillipsArticlesTesting ArticleBeing the sole tester, whether forming the beginning or the end of a test team, creates huge opportunities which are tempered by some hefty responsibilities. If you're the first tester hire in the company you may find yourself responsible for creating effective test processes across multiple teams. Perhaps you're responsible...