How to Plan the Perfect 'T' Party

Whatever the reasons for past failure, I was determined to have a better experience. As a former military officer, I had experience in building support teams; I hoped to draw on those skills when organizing our testing staff. This paper seeks to explore the techniques I discovered or adapted, as well as some that continue to evolve. I will share ways in which a testing manager can positively impact the professional relationships of software testers.

Testing Manager: The Hostess
"Leaders must take care of their people." Perry M. Smith

How exactly does a hostess plan the perfect tea party? She must decide who is to be invited and what they will be served. She must find a way to meet the guests' expectations while remaining within her budget. The hostess may require assistance in areas for which she has little expertise. She must use imagination and hard work to lay the foundation for a successful event.

When I became a testing manager six years ago, I found similar responsibilities awaiting me. I approached the testing process (or 'T' Party) much as a hostess approaches her tea party. My first order of business was to establish a theme, but I quickly determined that I would need more than one. To reassure management that a formal testing effort would prove beneficial, I selected the theme The results are worth the expense. For developers, I hoped to convince them that This invitation is too tempting to refuse. And finally, I wanted to interest prospective employees in the testing department with the theme Testing is fun!

The Perfect Job
To pull off a successful 'T' Party, I cannot work alone. But finding experienced testers is not always easy. I may have to encourage people from other software disciplines to join the team. On the face of it, testing may not seem like a very promising profession. Testers' jobs are thought of as destructive in nature, focusing on failure instead of success. Tester recommendations are often ignored or overruled. Testers work on a daily basis with software developers, a group not always known for humility, patience, or politeness.

So, to attract quality staff, I set out to shape the perfect job. I focused on three characteristics that made testing ideal for me.

• Challenging: Technical challenge is built into my division's software, which includes client/server, data access, messaging, and Web-based products. The testing group has used a technique called rotation, where each tester rotates through the product line two or three times each year. As the product line and testing department have increased, I have abandoned rotation in favor of specialization. To ensure that junior testers do not "get stuck with the dull stuff," every tester participates in all aspects of testing--from designing and writing test cases to running regressions and supporting tools.
• Worthwhile: The ideal job should give opportunities to contribute to software quality in a variety of ways. Testers see the tangible value with every defect prevented or detected; each missing bug is one less to hamper our customers. But more than that, testers can impact the long-term satisfaction of our customers in subtle ways. Physically locating testers near developers promotes regular exchange of ideas. This proximity to developers facilitates a tester's ability to provide early feedback on the usability and feature sets delivered in the software.
• Fun: I believe that the perfect job should be a lot of fun. Testers may experience some fun individually; there is nothing like the thrill of hunting down an elusive bug! But we also try to inject humor in other ways. We spend almost as much time laughing as we do exchanging status information in our staff meetings.

Filling Positions
With the ideal job defined, the hostess has competitive positions to offer. The focus now changes to what applicants offer in return. Technical competence and solid credentials are only the basics. Just what will separate the ideal applicant from the rest of the pack?

• Diversity: A well-run party needs different kinds of workers: waitstaff, caterers, and musicians, to name a few. For my 'T' Party, the characteristics I look for in an ideal applicant change with each new position. I do not need clones of my current staff; I need complementary skills. My testing department has much diversity: males and females; those with Computer Science degrees and those without; backgrounds in Quality Assurance, Technical Support, Marketing, Testing, and Development. This breadth of perspective enhances the group's ability to perform.
• Attitude: Testing is a support function. I seek individuals who have the subtlety and self-confidence to serve in a support role without becoming doormats.
• Real People: I look for real people with real lives. I value individuals who can channel their creative energies into nontechnical outlets. I have found that they return to the office with the freshness and focus that complex technologies demand. I don't need geeks, gurus, or golden children.

Keep 'Em Happy
A hostess cannot afford to have the staff leave before the party ends. Neither can a testing manager, whose job is not over once the applicant says yes. Retention is a critical problem in any career field. The testing manager must keep testers saying yes every day. What motivates them to stay? What can I as a manager do to keep 'em happy?

• Be Trustworthy. My staff must trust me to take good care of them. I am committed to providing for their well-being. As manager, I find myself serving them in three major ways.
• Organizer: When their professional and personal lives fit smoothly together, employees can bring a higher level of concentration to their duties. I want to promote the idea that this job is part of a daily continuum. Therefore, I try to organize their work environment and schedules with as much flexibility as corporate policies allow.
• Coach: I function as a combination of guide and critic. I help to define their objectives and priorities. Because I am also a tester, I can provide technical assistance and constructive feedback.
• Protector: I am fiercely protective of my staff. They can count on me to stand by them and back them up.
• Minimize Stress. The Perfect Job would have minimal stress. I consider it part of my job to reduce, deflect, or absorb external sources of stress. My staff is not held accountable for anything that they do not control, including The Code!

Testers: The Hired Help
"You can lead a horse to water, but you can't manage him to drink." Anonymous
While planning the perfect 'T' Party, the hostess must resist the urge to plot out each and every detail. Instead, when surrounded by capable people, she should encourage her staff to function as a team of co-hosts. If the employees view themselves as part of a cohesive unit, they will look within their team for advice, assistance, understanding, and support.

As a manager, I encourage an informal support network among the testing staff. Key to this relationship is the ability to regard each other with a cooperative and noncompetitive spirit. Of course, I cannot make staff members like anyone else. But I have found a couple of ways to maximize the likelihood that they will respect and rely on each other.

A Stake in the Outcome
When they are given the opportunity to impact the decisions that affect their professional lives, employees feel incentive to see those decisions succeed. Our staff has been given a stake in the outcome in the following ways.

• Testing staff are encouraged to participate in the interview process. Panel interviews and post-mortem discussions allow them to provide input into the selection process.
• Current staff have responsibility for training new testers. They serve as mentors to newly hired members, focusing on software products, testing tools and testing processes.
• Staff members often travel to training courses in pairs so that they can learn together.
• The testing department indulges in an annual Professional Development Week. Normal duties are suspended for five working days. Staff members choose one or more technologies to investigate, frequently working together to build new skills.

Retreats
We take time off several times each year for off-site retreats. Sometimes we participate in formal team-building programs through the company's Management Education department. Other times, we meet for an extended staff meeting to discuss important issues facing us. Whatever the vehicle, the testing team leaves reacquainted both professionally and personally.

Developers: The Guests
"We must all hang together, or assuredly we shall all hang separately." Benjamin Franklin

The plans for the party are complete. The hostess knows what will be served. She has selected the right mix of guests, ingredients, and staff. With the invitations sent, the hostess anticipates the start of an exciting event.

As testing manager, my guest list for the 'T' Party is pre-set. I do not spend as much time on what will be served as how to serve it. With help from an eager and well-trained staff, I know that I can pull off a great event. So, my challenge now is to convince the guests to come. To accept the invitation, the guests must expect good service and the staff must deliver.

So, how do developers define good service? Do they limit it to finding bugs? I have not found that to be true. As developers become aware of what testers have to offer, I find that they expect testers to participate fully on the development team. Here are the characteristics I have used to facilitate strong relationships with developers.

• Credibility
  Testers may need to prove their technical competence to developers. We have to be amazing. I suggest the following two ideas.
• Testers must perform well and in a timely manner. Testers should work hard to find that initial defect. First impressions are critical and bad ones are hard to salvage.
• Developers may not realize that most testers have the same credentials developers have. When the opportunity presents itself, testers should mention past experience or educational background.
• Positive attitude
  Testers need to be positive and approachable. Testers should be careful when discussing their findings with developers: no gloating, no whining, no superiority! Testers can try to couch negative messages in positive terms. If asked to meet an unrealistic schedule, a tester can make a no sound nearly like a yes. For instance, instead of There's no way I can get all this done in two weeks, try: I can do an adequate job with two weeks, but I could do a great job with four.
• Reasonability
  In an ideal world, software development projects would faithfully exercise quality processes. Well-written design documents would be delivered on schedule. Test plans would be carefully crafted and implemented. Testing cycles would never be shortened. So, how many of us work in an ideal world? Instead of playing the blame game, testers should have the reputation for pitching in. If testers do not get written specifications, they should document it and move on. Priorities change. Software professionals have to be adaptable.
• Reliability
  Testers should be accountable for providing consistent, quality support. Good first impressions can be ruined by a pattern of shoddy or sporadic work. When circumstances prevent testers from doing their best, they must be honest about it. Developers need to be able to count on testers to meet commitments. Developers must know they can rely on testers to make fair, honest assessments of software quality.

When Guests Don't Show
As she monitors the progress of the party, the hostess is gratified to note that all is going well. Early feedback from the guests suggests that expectations have been met or exceeded. Still, a quick look around reveals that participation is not 100 percent. What can the hostess do when guests don't show?

Here is a situation in which testing managers must take an active role. Staff members derive satisfaction from contributing to successful projects. If denied that sense of accomplishment by the developers on the team, testers may experience a serious impact on their morale. The testing manager must step in or risk losing testers. When faced with such problems, I have tried the following ideas to fill the void.

• Appreciate: Make sure testers are getting the recognition they deserve. Make a special effort to praise them individually and as a group for their hard work.
• Try alternative projects: Give testers opportunities for career-broadening assignments, preferably on enlightened development teams.
• Make personal visits: Visit the developer(s) to determine the problem. Personality conflicts happen; reshuffling resources may help. Perhaps the developer has unrealistic expectations of tester responsibilities which could be cleared up in a frank dialogue. 

Management: The Sponsors
"Written reports have purpose only if read by the king." attributed Attila the Hun
Through ingenuity and teamwork, the hostess and staff have worked hard to throw a great party. The guests are having a good time. But it is not enough for the hostess to believe in the party's success; the guests have to tell the sponsors. For the sponsors to continue support, they must accept that the value received is worth the expense.

Style and Substance
At the 'T' Party, formal testing efforts are the expense; enhanced software quality is the value received. I know the testing staff is making a difference, and now I need management to believe, too. First, I need to demonstrate that testers leave the software cleaner and better than they found it. The company's defects tracking tool helps me to get this part of the message across. Managers can easily monitor the volume and seriousness of defects through the tool. Second, I must communicate the message in a style that managers will appreciate. I need to provide the right amount of information at the right time. Whether in verbal or written reports, I focus on these elements.

• Brevity: Too much information can be worse than none at all. To quote my high school English composition teacher, "Anything that can be said in ten words may be better said in five."
• Clarity: I limit reports to metrics that are self-explanatory, such as percentage of testing completed or estimated workload.

Word of Mouth
Testers enhance software in other, less tangible ways. They can bring a user's perspective to design discussions. They provide early feedback on software prototypes. The mere presence of testers, armed with test plans and questions, can encourage a quality mindset in developers. None of these ways can be measured objectively but all contribute to the quality of the product. Developers know; they sense the difference.

The guests at my 'T' Party have been vocal with their appreciation. I have heard developers worry out loud that the testers are being stretched too thin. I have had developers cheer when I shuffled workloads to cover their projects. I have had product managers send their new developers to the testing staff for training. Satisfied by a history of good service, our developers have become tester advocates. And management is paying attention.

The Measure of Success
"Discernment is often far more accurate than either observation or measurement." Stephren R. Covery
In this paper, I have presented techniques that a testing manager may use to nurture the professional relationships of software testers. I feel confident that these techniques are working in practice. Here is how I have measured their success.

• Retention: I have worked to deserve the trust of my staff. I keep employees happy by challenging them through their jobs and by creating a comfortable work environment. If employee retention is a measure of success, I have done well. In the eight-year history of our division's testing staff, only one employee has left.
• Teamwork: I want my staff to respect and rely on their fellow testers. Whether through their participation in the hiring process or in regular staff meetings, testers have made an effort to stay in tune with each other. Teamwork pays off; prospective applicants often say that the reputation of our group helps to attract them.
• Collaboration: Through diligence and positive attitudes, the testing staff has convinced developers of testing's effectiveness. Developers include us at earlier and earlier phases in the software lifecycle. They seek our opinions, use our tools, and embrace our presence on the development team.
• Support: I need management to recognize the valuable contribution that testing and testers make to the quality of the software. With clear, concise communication, I believe I have delivered that message. My manager has responded with strong support for the testing staff; his division has one of the best developer-to-tester ratios at our company.

I have presented some subjective ways that I measure success. However, in an attempt to gauge my staff's impact a little more objectively, I conducted a software quality survey at the Institute. I sought the customer view of quality from the Technical Support Division. I queried developers and testers about the development processes and relationships in their respective divisions. Information on the survey is summarized in the Appendix below.

I hope that the management tips described in this paper trigger some useful ideas for other testing professionals. Clearly, I believe these techniques have contributed to the success of my testing staff. And I agree with Dr. Covey: we can rely on our ability to discern success. I will close with an anonymous quote from one of our developers: "One of the keys to good software is the interaction between developers and testers. Both are absolutely essential for a great product. When both are striving to do their best, there is no better situation."

References

• "Covey, Stephen R. The 7 Habits of Highly Effective People (New York: Simon & Schuster, 1989).
• Smith, Perry M. Taking Charge: Making the Right Choices (New York: Avery Publishing Group Inc., 1988).
• Roberts, Wess Leadership Secrets of Attila the Hun (New York: Warner Books, Inc., 1989) 

Appendix
Software Quality Survey Results
Survey Background
In an attempt to measure the success of my division, IDB, I created a survey for the development staff in SAS Institute's R&D. I also asked our Technical Support staff to participate, to provide a customer-oriented perspective. I was seeking to answer the following questions:

• What is the customer view of our software quality?
• How do developers view their interactions with testers?
• What quality processes do developers use?
• How do the testers view their interactions with developers?

I made the survey purely voluntary. I did not use random-sampling techniques in collecting the data. Therefore, I cannot draw conclusions with any level of confidence. In fact, the response rates from developers were so poor that I will not include their results here. Response rates from Technical Support and Development Testers are included on the bar charts.

Survey of Development Testers
What amount of testing do your developers perform before handing code to testers?

How much contact do developers and testers have in your area?

Survery of Technical Support
What are customers' assessments of the quality of this product?

This paper was presented at StarEast 1998.