- The Software Test Team and the Development Team
- The Software Test Team and the Product Design Team
- The Software Test Team and the Customer Support Team
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Software Test Team and the Product Design Team
Let's examine another scenario. Kevin, the product design manager, had years of experience working with the company's software, and the application currently undergoing a major upgrade was considered his pet product. He knew many of the customers personally; certainly, he knew the primary contacts at each of the large customer accounts. But Kevin was uncomfortable and unfamiliar with software testing. I started working as the quality assurance manager at the company just a couple of months before the product was scheduled for release.
This product upgrade was scheduled to have a user-acceptance testing (UAT) session by several customers late in the process. Kevin wasn't sure what to do. Closely involved in the upgrade from the start, he had defined the features, planned the product re-launch, and arranged for printing all the marketing materials—but the UAT was undefined, and Kevin was apprehensive.
I approached Kevin and offered help, which he readily accepted. I figured I could carve out several scenarios that users could execute, giving them some ideas of what to test. I focused on scenarios that would demonstrate the new features. I also created several user scenarios designed to step through existing functionality. Kevin was relieved when I gave him a preview of the materials for the UAT session.
I asked if I could run part of the scheduled meeting, hoping to accomplish a couple of things. I could explain to the users that the scenarios had been written as examples, as ideas to help spark testing, but users should feel free to explore the upgraded application and peruse the new functionality. Second, I hoped that users would share their product knowledge with me, pointing out flaws in the scenarios I had written; even better, offering ideas for other scenarios that I could incorporate into future testing. I figured that the users would be training me while I was coaching them. What I hadn't anticipated was how much goodwill was created between us by my offer to help.
Certainly, one of the fastest ways to build goodwill is to offer to take on work. I'm not suggesting blindly accepting work or losing sight of what's achievable. Instead, find ways to bridge gaps between groups.
Not all projects end smoothly. In the case of the UAT session, Kevin didn't want anyone from the company other than himself to be involved in the session. He felt that the relationships were his. I was told firmly that my materials would be used, but that I was not welcome to attend. My point here is that not all working relationships will be forged as well as we might like.
We should work toward making a product be a solution, and not just shipping a product. I like to ask myself what I can do toward that end.
Here are three ideas to build strong working relationships between the testing team and the product design team:
- Ask for early copies of any design documentation. An easy way to show interest in the product design is to offer to preview the copy. I have been able to get early access to design documents by being willing to review and provide feedback on copy before distribution. The small labor of proofreading is worth the effort.
- Give feedback on design. As soon as you can reasonably provide feedback on design, offer suggestions. If the team dynamics are such that offering feedback is misconstrued as criticism, pay close attention to when and how you deliver feedback. If the environment or the team dynamics still make offering comments challenging, consider sharing how your team will go about testing the product. By focusing on testing, you can communicate design flaws without sounding like you're critiquing the product design team.
- Invite testing ideas. In one environment, I worked with a product designer who was used to providing feedback on the testing efforts planned. Tom might have been opinionated, but his ideas were great. When he felt I was interested in hearing his ideas and how I planned to use (or sometimes not use) his ideas, the teamwork between us improved.