If you work for a team where the testers are brought in late in the cycle to test software that is almost finished, this question asking may seem a strange role for testers. But it is one of the most valuable activities a tester can do. My favorite tester story involves Human Resources at some company asking the requirements team, the development team, and the test team to write a 100-word description of what they did. The first two groups complied with typically boring statements. The testers sent back the following note:
Who is this description intended for? Why do you need this? When do you need this? What language do you want this in? Do you want to include only full-time testers? How about contractors? Why is it important that it be 100 words? Is that a lower limit or an upper limit? How do you want to count the words? Do hyphenated words count as one word or two? What format should this be in?
What a great reply! Rather than merely describe what testers do; it showed testers in action!
How Much Is Enough?
You may argue that some of these questions are too picky and lawyerly. And you may be right. Perhaps we don't care about all the details, but we do care about having enough details so that we understand what we're talking about and don't make too many costly mistakes. As long as the questions are asked, we are aware of the issues even if they get tabled for future discussion.
And you never can tell who will come to your defense in asking seemingly picky questions. At a spec review a few months ago, one tester was drilling down on some functionality when the spec writer said dismissively that such questions were too picky. There was a hush in the room until the developer on the feature spoke up "No, it's not too picky at all. The requirement is ambiguous. I want to know what it means so I don't have to guess and end up rewriting the code several times." It was a great moment—an unambiguous vote for clarity and quality!