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.
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.
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.
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