Testing is a complicated job, and testers are required to wear many hats, especially in smaller organizations. As a result, many testers focus on a single project or feature, often feeling that driving impact is beyond the scope of their job.

In large corporations, test managers generally advocate for the testing organization and use that to leverage change, but at startups or small companies, making change is different. Often, one or a small group of testers must decide how they will make the entire system work, as well as designing and implementing one or several aspects of the system.

In my work with various small and mid-sized start-ups, I have been a lone tester who has researched, designed, and implemented test change across an organization. In this blog, I’ll share some of the techniques I have used to drive impact.

Technique 1: Qualitative Interviewing as a Tool

Information is everything, and the best sources of information at any company are its people. Customer success, sales, and developers all have different kinds of information and experience with the product. Oftentimes, this experience is not recorded in an official capacity. My training in qualitative research has helped me learn about a company by learning the needs, accomplishments, and frustrations of key product stakeholders.

You don’t need to be trained in qualitative interviewing to use the techniques as a learning tool. There are several books and websites that introduce the basic tenets of qualitative interviewing. In Qualitative Researching, Jennifer Mason recommends the following interactions when engaging in qualitative interviews:

Make sure that the questions are sensitive to interviewees’ experience, needs, and circumstances

Keep the interview focused on the information you want to learn

Ask open ended questions and practice active listening

Remember what has been said, and also attend to non-verbal cues and reactions

Ensure you are comfortable with recording equipment if you are using it; equipment shouldn’t impede interview

I used this technique for my first job as a “Lead QA Engineer”. I interviewed all the team leads, from sales to customer service, to hardware installations and maintenance, through the engineering team. Each interview provided me with a more broad understanding of the needs, desire, and pain points experienced by other teams.

Using these interviews, I was able to identify “sore spots” across teams and use that to prioritize my work in building the automated test framework, as well as building process for manual testing of hardware and software. Having information from multiple sources helped me to focus in on shared problems and solve those first, developing trust among different stakeholders.

Technique 2: Draw it, Write it, Sing it, Build it

Once you have learned about your organization and the stakeholders, it can be tempting to get into your tester’s mindset and focus strictly on the needs of testing within the organization. Whether you are new to your organization or simply trying to view it through a different lens, take the time to get into a creative mindset.

What exactly does a creative mindset look like in a development organization? Sometimes it means making physical drawings or whiteboarding ideas. Perhaps you prefer to use construction blocks or other physical means. Maybe it means thinking about structures like those in music or literature and using those structures to inform your thinking about your organization and the role of QA in the larger picture. Sometimes, a word cloud or other visual can you visualize the priorities of your organization.

While employing artistic means might seem frivolous, I have found that using artistic or creative means helps me bring all of the information I have learned together in new ways. Viewing information in novel ways has helped inform my strategies and problem-solving.

Many testers are fond of drawing mind maps and use software for the purpose. There is a phenomenal mind-map book I picked up back in 2003 when I was teaching in a classroom for the first time called The Mind Map Book. This book has been my go-to when working to visually represent a problem, as it attends to the creative thinking processes inherent in drawing and creating mind maps without software.

A few years ago, I used an artistic mind map to envision the role, needs, and issues of each stakeholder as I was devising an application security strategy for an organization. I created a drawing of the organizational relationships and needs, and then added the layers of OWASP OpenSAMM, making connections between the things our organization was already doing, and the things we needed to do.

Having a literal picture allowed me to visualize some of the complexities that needed to be addressed, as well as the relationships that already existed and those that needed to be built. The mind map I made was more than words connected by lines — ideas were connected with color, and sketches of relationships, people, and tools were included in the flow.

Technique 3: See it, Say it, Do it

Speaking change into life requires vision, commitment, and tenacity. What we see as good for our organization may not align with what others see. Yet, if we take the time to interact with stakeholders from every team, we can construct a vision that addresses community values and concerns, with an eye toward quality.

Effectively sharing and shaping our vision, while making sure to hear and address the concerns of others, is probably the most difficult aspect of being the lone tester. I have experienced times when my enthusiasm for change meant that I left people out or did not hear their concerns. This resulted in damaged relationships. While I did learn from those early experiences, I wish I had known what I know now so that I would not have to repeat them. Last year, I gave a talk about some of these techniques; I will briefly share a few now.

First, share your vision with the goal of getting feedback, not buy in, from others. A vision shared with the goal of buy-in has already been decided upon and can come across as exclusive of the needs of other stakeholders. When presenting your vision for change, invite feedback and listen to criticism.

The best thing I have tried is asking people to clarify their concerns. I dig regularly into my knowledge of Dialectical Behavioral therapy as a tool to help me with interpersonal communication. So, if a coworker says: “I have serious concerns about implementing this program,” I will respond with “I understand. Can you tell me more about your concerns?” This validates that I am truly listening to my coworker and taking their opinions into consideration. This also keeps the focus on the topic of discussion and keeps things from becoming too personal.

Taking feedback and incorporating it into your vision is necessary if you expect people to respond to changes you wish to make. During any follow-up conversations or presentations, make sure to note where and how you addressed the concerns voiced by others. Even if you needed to make a decision that was counter to one of the concerns voiced, you are showing thoughtful consideration of the entire team by addressing their issues.

Finally, lay out your plan, step-by-step. Some plans for quality, like “implementing stronger security,” sound great on paper, but are significantly harder to implement due to their complex nature. What does “stronger security” look like? Who is responsible for making sure that “stronger security” is achieved? Make certain that you are able to answer specific questions about costs and benefits of action.

Driving impact as the sole tester in a small or even mid-sized company is not easy, but it can be accomplished. First, learn your company and teams really well. Then, create your vision for quality in your organization. Finally, share that vision with others and take their feedback seriously so that you can enact your vision in the way that best suits your company.

About the Author: Dr. Jess Ingrassellino is a Senior Member of the Technical Staff on the QA team at Salesforce.org where she focuses on technical testing and the Founder of TeachCode.org where she continues to develop curriculum and training programs. Jess is also chair of the PyCon Education Summit, the Project Leader for the OWASP Learning Gateway, as well as a teacher, an author, and a musician. To learn more, follow Jess on Twitter or check out her blog.