What motivates a good tester?
July 13th, 2007 by Eric Nehrlich
In my last post, I discussed the qualities that made for a good tester. And Joel explains why a company should hire testers. But what motivates a good tester?
When I asked "Jill the Very, Very Good Tester" about how she approached her job, she stated that her two main responsibilities were to the end-user and to the company. Let's explore what she means.
End-User Responsibility
Look around a typical software company. You'll see that it's a technology-centric environment. Everybody there can configure their own computer, has a complicated cell phone, and plays video games with interfaces so complex that only a teenage boy could learn them. When they interact with technology, they know what the designer was trying to do because technologists have similar mindsets. Since they only interact with other technologists, it's easy for them to forget that not everybody thinks like they do. For instance, an ex-coworker once uttered with a straight face, "That's not a bug! We have a 15 step workaround for that, so we don't have to fix it!"
The tester's job in such situations is to be the user advocate. They need to explain how the rest of the world will react to the technology by constructing reproduction cases with the structure of:
- 1,2,3) This is what I did.
- Expected: This is the result I expected.
- Actual: This is the result I got.
Such cases demonstrate for the developers what the expectations of the rest of the world will be. A good tester will anticipate the reactions of the non-technologist end users and catch unexpected behaviors before they are released to paying customers.
Company Responsibility
The tester also has a responsibility to the company. They manage the risk for the company by providing clear feedback on the current status of the software and its readiness for release. We all know that when a developer says they're 90% done, they're about halfway there. But we need testers to inform the developers and their managers of the true status.
A tester will document what works and what doesn't in the software. They have test plans written, with a method for exercising every feature described in the specification. They deliver the current status to make it abundantly clear how far the project is from being complete. One of Jill's suggestions for reporting is in the form of a two-dimensional matrix, where each feature is tested on each of the different deployment platforms; once developers see all the empty spaces, they will be less convinced they're almost done.
There will be pressure from management to give convenient answers, but it's the tester's responsibility to deliver accurate information. Managers can not make the right decision on whether the software is ready to release without the truth. They may decide to release it anyway, but then they are making a fully informed decision and are less likely to be surprised later if their customers are outraged.
Sounds awesome, doesn't it? The tester as the representative for the Common Man, and the standard-bearer for Truth within the organization. Things rarely work out so nobly for the poor tester, but I thought Jill's perspective may explain why she's a "Very, Very Good Tester".
Share this article
