The Challenges of the Lone Tester: Learn to Thrive

There is no question that there are great opportunities for improvement when it comes to testing teams and organizations that employ them. A discussion less frequently addressed is when individual testers are the entire test team.

Various names have been applied to this: the lone tester, the army of one, the omega tester, etc. Regardless of the name, the situation is the same. We are the sole resource for a specific project, or for a development team, and often for an entire company. As more companies move from traditional to Agile development practices (or start with Agile practices from the beginning), the idea of a dedicated test team is fading in favor of self-organizing teams that share a number of disciplines, testing being one of many needed skills. As a lone tester, my efforts take on an interesting hue. It’s all on me. I really am the last line of information to the product team as to what identified dangers exist inside of the code. Sobering is a good word for this situation.

There are certainly benefits to being a lone tester. It’s a very liberating environment. We often get the freedom to test in the manner that we find the most effective. Decisions around tools and processes are often tailored to our own needs and niche abilities. Our efforts are often seen as the last line of defense for the product team. We also run the risk of becoming silos if we are not careful. Knowledge that we develop is more likely to be locked to us unless we take the initiative to share the knowledge we have. Also, other testers cannot cover our deficiencies. Holes in knowledge and experience will have to be filled in by active work and learning, and needs for knowledge and experience may change over a period of months or, in some cases, days.

So how can we thrive in this environment where we may well be the only active
voice for testing?

1. Focus on Communication
   Communication can be difficult, because we are the only voice speaking for the bugs in the system. That’s not to say that developers do not care about bugs, they certainly do, but they are often focused on their own features or their specific release. All bugs are not created equal, and the perception of which bugs are important and which are less important are addressed every day. The lone tester must be brave enough to speak up and advocate for the bugs that are not having enough light shined on them. The responsibility to stand up and speak for those bugs belongs to us.
2. Learn the Expectations of Your Development Team
   When a team relies on a lone tester, there has to be a give and take as to what can be accomplished in any given time frame. Lone testers do not fail because they are by themselves; they often fail because they have made an unrealistic expectation as to what they can actually do. Assess your abilities, your strengths, and your weaknesses and present them honestly. Realize that it is OK to not be an expert in everything (nobody is). State clearly areas where you perform well and areas where you will need to improve, and stay vocal about it. Many of your team mates will be happy to help you learn what you need to learn if they can; your success helps them succeed as well.
3. Stop Thinking in Terms of Us vs. Them
   It has become part of testing folklore that development and test are adversaries and that we are somehow doing battle with or providing protection from development’s mistakes. It makes for cute stories, but it’s not a very effective method for working with a development team. When you are working with a development group, you are effectively a consultant providing a service to that team. Work and behave accordingly. Be honest in your evaluation of issues, but make sure your focus is on fixing issues and getting a well tested and solid product ready to be released.
4. Learn How to Work with the Development Tools of Your Organization
   Is it possible to be an effective tester without knowing the inner workings of the code? Yes, and in many cases it’s more desirable than knowing the structure and underpinnings of the application I am testing. Having said that, I also believe it is important to have familiarity with the languages, methods and tools that my organization is actively using, and having some familiarity with how they work and what is being developed. That also goes for understanding the automated tests being used, whether they are at the unit, integration or functional level. This has been a challenge for me personally, but it has given me a better understanding as to the many moving parts that make up the applications I have worked with over the years. It’s also helped me devise additional test scenarios because I understand which parts interact with each other.
5. Plan for Pairing Sessions with Developers and Domain Experts
   Pair programming is used in extreme programming and Agile. Pair testing is also an effective approach to evaluating software. While it would be great to have two testers working together, a tester and a developer also make for a great test team. Additionally, pair testing with customer support representatives, marketing team members, sales, and even executives can be very helpful. Each group in an organization has a different perspective, and each group has its own level of expertise. Pairing with the experts in my organization has given me many insights I might not think about were I to focus on testing by myself. Some of the best user experience questions and insights have come from regularly pair testing with customer support representatives; they know the customer pain points better than anyone.
6. Cultivate Relationships with Mentors
   Lone testers have additional challenges when they are looking for mentorship; who can they turn to? For me, if I cannot find someone in my own company to mentor me, I look outside of the company. The testing community has many dedicated people who are happy to share their knowledge and experience with other testers. I suggest lone testers look for other lone testers to discuss ideas, get input and feedback on ideas, and work together to help build understanding and have opportunities to grow. Social media outlets like Twitter, Facebook and LinkedIn also give testers the opportunity to find and follow each other’s discussions and add their own comments, which in turn can be considered and challenged by others.
7. Develop Your Craft
   Coursework like the Association for Software Testing’s Black Box Software Testing series can help testers learn new strategies and ideas for testing approaches and ideas, as well as to reach out and meet/communicate with other testers. Conferences, meet-ups, code camps and discussion forums can help introduce individual testers to other testers looking to share ideas and methods. Also, I’d be remiss if I didn’t mention Weekend Testing, an initiative I am actively involved with. Weekend Testing is a regular gathering of software testers to take on a challenge and learn about testing in a safe and fun environment.

   Sessions typically take place on weekends (hence the name) but these sessions can be held any time. The key is to have a focus, and agenda, and a limited time frame to focus on testing and discuss the ideas learned. All of these are great ways to help sharpen the saw and hone our testing craft.

To my fellow lone testers, you are critical in the success or your organization’s endeavors. You have the potential to become indispensable. Many of the challenges you will face will be universal, and there will, of course, be challenges that will be unique to your organization. There is no one size fits all scenario for the lone testers out there. Although with the willingness to adapt and be open to your abilities, as well as the areas we need to improve on, we need not be solitary figures that live in the shadows. We can be seen as an essential element towards project success.

About the Author

Michael Larsen: I am a long time tester with experience covering networking equipment software, SNMP applications, virtual machines, capacitance touch devices, video games and distributed database applications/web services. I’ve also tended to work as a “Lone Tester” in many of these environments.

I can be found on Twitter at @mkltesthead and I blog at http://mkltesthead.com/.