In last week’s featured StickyMinds article, Karen Johnson talked about collaborating with her technical team early in the process—before the code was typed— in order to plan testing. In this piece, I'll cover pairing with other team members for test execution.

On a project I once worked on, I was the only tester on my cross-functional Scrum team; in this case, I was acting like a testing teacher. My prospective students consisted of a user experience/interaction designer, a product manager, and the developers; these students were my product team. I wanted to help them integrate testing with their work roles. In agile, the whole team owns the quality, so the whole team needs to be on the lookout for opportunities to improve quality. In my situation, however, I had never taught software testing before.

As the team's ScrumMaster, I was a servant leader accountable for removing impediments to the team’s ability to deliver the sprint’s goals or deliverables. I had no authority over team members, only the Scrum process (though I debate that). Mike Cohn says, "The ScrumMaster is often considered a coach for the team, helping the team do the best work it possibly can," and "They have authority, but that authority is granted to them by the team." Thus, quality is an inherently consensual goal that requires buy-in from everyone to achieve; in this way, I was already coaching my team. I hoped I could extend that relationship to include coaching about testing.

At the office, I experimented with paired exploratory testing as a means to observe my teammates' strengths, to discuss how testers think about software, and to counsel my team for better results. I already had success with two testers who paired up for an exploratory testing session, so I hoped that this approach would facilitate learning for the people without testing backgrounds. I was also looking at this as an opportunity to pull in people who would be "downstream" of the product team (i.e., devops, trainers, support staff, and salespeople).

With this practical experience of working with non-testers on testing, I was excited to lead a discussion for other professional testers. I wasn't sure whether I would be able to advance the practice of test coaching for the greater test community, but I was willing to find out. I did not have a formal presentation planned; I was much too nervous for that! Instead, I focused the small group on the question of how people with a testing background could coach non-testers for the benefit of the product team and ultimately the customer. It was a combination of experience reporting and gathering ideas from other attendees, who primarily focused on coaching other software testers.

Some of our discussion focused on the mechanics of completing the testing task. We talked about managing the exploratory testing work through timeboxed sessions, each with an explicit focus. Making the proposed testing work visible to the team allowed for input from many different points of view. Being in on the initial story meeting could better clarify the expectations for testing, but visible testing tasks allowed for later review and prioritization with the product owner.

We reflected on what non-testers should know about testing. People pairing on a testing task could start from very different points of view. These team members might never have worked in tandem on a task before. Skilled manual testing might not be a familiar concept or even known to be a thing. This could be their first time working with a professional tester. Teammates might think of tests as automated actions the computer performed to check the behavior of the code.

We wondered whether non-testers would be comfortable performing exploratory testing. To help them feel more at ease while doing something new, the test coach should cultivate a safe environment where test failure was not only acceptable but a good outcome. Using a test charter to guide exploration was quite different from their usual role-based duties. The test coach needed to explain the structure of the activity as well as helping to reflect back what the pair was doing. One technique I used involved bringing along a diagram of the focus area for this chartered testing session. I particularly liked using a site map as a cheat sheet. When our testing started to veer away from the intended area of exploration, the test coach could pause the activity in order to discuss the decisions we were making. That way, we could deliberately choose to leave the charter behind or spin off a new charter for future consideration and stick to the current loosely-defined plan.

We recognized that co-workers from other disciplines might not keep the same records of their activities. How would non-testers log their testing work? How would they create feedback for the team? Was an overall gut feeling a desired or acceptable result? This consideration felt more like we were trying to understand our peers and their information needs rather than shaping their results. After all, the mental models and attacks that our colleagues used were not necessarily what we as testers would use, especially when the pair was the developer who had produced the software we were exploring! We were able to talk about whether exploring your own code was a difficult task and how to break out of the creator mindset into a distinct explorer perspective. Along the way, we discovered that different team members were concerned about different risks. This revealed that each generalizing specialist contributed unique value to the work of testing.

Exploring together opened up an opportunity to discuss pairing patterns and practices that the particular team valued. We could discuss how and when to present questions that resulted from the exploratory testing we had completed, recognizing that questions were no less valuable than defects. We considered whether the team valued detailed logging of testing sessions for defect reporting or whether the high-level summary information was enough for an initial investment. This negotiation streamlined the testing practices as well as establishing a norm for capturing information.

You need to figure out whether one pair is enough for you or whether a testing party would be more helpful. The team could establish a norm of executing concurrent test sessions with the testing coach free-floating among the exploratory testing pairs. By facilitating the work of many people rather than focusing on just one individual, the testing helpers had more personal freedom and room for learning. This would be especially valuable when debriefing as a group, sharing what worked and what didn’t work.

Once people were comfortable doing exploratory testing, other disciplines could pair without a tester riding along. User experience designers and developers could review a story together before considering the code ready for investing testing time. Story acceptance testing by a business representative could become a formal pairing exercise focusing on predefined acceptance criteria as well as the overall value of the unit of work. Customers and developers might pair during scheduled workshops, hearkening back to the practices of eXtreme Programming.

As we closed the discussion, my mind was awhirl with many ideas for future experiments. I was excited to hear that other testers were considering how to involve non-testers in testing, whether through pairing or some other approach. My takeaways? An important part of encouraging others stepping outside their bounds is praise. Emphasizing the fun of exploring together can motivate others to learn more about testing. Although I want to be a testing mentor and role model, I should also provide suggested resources for my teammates to learn more about testing in their own way and at their own pace. While the other folks may not choose testing as their future path, sharing an understanding of how to execute testing helps the whole team.