There are two types of managers, those that are happy, even eager, to work with their colleagues and those that don’t pay much attention to anyone else unless they have to. If you’re a busy software test manager— that’s probably redundant—you probably can use all the help you can get. All you have to do is have a conversation with your “natural partner” and suggest a mutually beneficial plan for testing software.
You may not have thought about it before now, but if you consider the synergy that can take place when the departments work together, you’ll find that you have a willing partner. Partnering with your colleagues in the support department is, as Stephen Covey has written, a “win, win.” The testing department and the support department have, at a minimum, the following concerns in common:
- Find important bugs fast
- Provide a general assessment of the quality of the product
- Certify that the product meets a particular standard
- Help your clients improve product quality and testability
- Assure that the test process meets accountability standards
- Educate your clients about testing and how to work with testers
- Follow a particular set of methods or rules
- Help predict and control the costs of support
- Help your clients improve their processes
- Perform your work in a manner that minimizes cost, time, or undesirable side effects
- Do whatever is necessary to satisfy particular clients.1
What’s more, using technical support personnel as testers allows the testing department and the support department to gain an in depth understanding of how the application works. Such knowledge is invaluable in preparing both the technical support and the customer for rolling-out the software.
In addition, “Testers can gain another perspective on the software by meeting with customer support professionals, especially if they are servicing customer calls or problem reports in a similar functional area. They are very familiar with the types of problems customers are reporting, and can share their thoughts on serviceability needs and how hard or easy earlier software was to debug. You’ll gain insight into the types of problems that escaped previous test efforts, and you can make note of additional tests to include in your plan. Pay particular attention to any interesting combination of events that are not self-evident but have occurred in production environments and subsequently exposed a defect. For example, support reps may describe a scenario where the software reacted incorrectly when system memory was constrained because of an activity spike of a completely unrelated software application.”2
Activating this partnership begins with a conversation between both parties. If the support manager initiates the conversation, he or she need only be genuine and say, “How can we help?” If the positions are reversed and the testing manager initiates the conversation about the support staff assisting with testing, it is important to remember that the WIIFM? (What’s In It For Me?) question must be answered completely. Support managers – like their brothers and sisters in the testing world – have numerous and complex duties and adding another item to their task list is not always welcomed. This is where the importance of WIIFM comes into play.
There are as many approaches to recruiting assistance as the imagination can generate, but they all have the same characteristics, they respect the time of those rendering assistance. This is especially important for technical support people, their every move is part of a staffing and scheduling model so if you want assistance, you have to be precise about what they will be doing and when they will be doing it. This is where the RACI matrix is valuable; show the support manager what the volunteer testers will be doing and you’ll score some very important points.
” Testers can gain perspective on the software by meeting with customer support professionals, especially if they are servicing customer calls or problem reports in a similar functional area.”
Of equal importance, is selecting and training the folks from the support department that will be working as testers. The days of grabbing people from a hallway, giving them a script and a stopwatch and saying “Go to it,” are over. Your volunteer testers should, at a minimum, be trained in the basics of software testing. They don’t need to understand IEEE 829-1998 (Standard for Software Test Documentation), but they should have a basic understanding of the testing process and their role in it. For example (a very, very general example):
First Things First
- Check the scripts assigned to you
- Check the status/comments of the defect in the Test Report Tool
Checks While Executing Scripts
- Take screen prints for the script executed using naming conventions & provide
test data that you used for the testing - Don’t forget to update all the tracking sheets for the bug, it’s status, time &
date found, severity - Update the tracking sheets with current status, status in reporting tools, etc.
- Check if you have executed all the scripts properly & updated the test reporting
tool - After you complete your days work, it is better to do a peer-to-peer review
Checks While Logging Defects
- First of all, confirm with your test lead if the defect is valid
- Follow the appropriate naming conventions while logging defects
- Before submitting the defect, get it reviewed by a Work Lead/Team Lead
Checks for Blocking & Unblocking Scripts
- Blocking or unblocking of a script relates to a bug which affects execution of a script. For example, if there is a bug on the login screen, which is not allowing anyone to enter the account after entering valid username and password & pressing the OK button, there is no way you can execute any test script which requires the account screen that comes after the login screen.
- Confirm with your test lead/work lead that the script is really blocked due to an existing bug.
- At the end of the day, send an update mail to your Team Lead/Work Lead which includes the following:
- Scripts executed (Number)
- Defects raised/closed (Number)
- If any comments added on defects
- Problems/queries
Finally, remember to set expectations clearly about what will happen while the volunteer testers are at work, when the testers will be needed and what will happen if the technical support center becomes busy to the point that the volunteers are needed back at their desks. Making all of this happen will require more than one conversation, but if both parties are willing to work together towards a common goal, any problems will be fairly easy to resolve and the value of having contact center employees involved in the testing process is incalculable.
“Set expectations clearly about what will happen while the volunteer testers are at work, when the testers will be needed and what will happen if the technical support center becomes busy to the point that the volunteers are needed back at their desks.”
1 Lessons Learned in Software Testing, Cem Kaner, James Bach and Bret Pettichord, 2002,
2 Software Testing Techniques, Scott Loveland, Geoffrey Miller, Richard Prewitt, Jr., and Michael Shannon, 2005, page 85.
3 URL: http://blog.practicingitpm.com/2010/08/02/clarify-roles-and-reponsibilites-using-a-raci-matrix/ Retrieved on January 26, 2011.
About the Author
Bob Last Bob Last is the Director of Research & Content for Redwood Collaborative. He has over 20 years experience in the contact center and technical support industry as a manager, trainer, consultant and analyst.