The question was posed: "How does a tester help with requirement gathering?" A number of good, but conventional, answers were given, so I decided to take my answer to a meta-level, like "what is the tester's job, generally, and how does that relate to this question?"
The tester’s job is to test, that is, to provide information about the state of a system being built or repaired. Therefore, the tester should help with requirement gathering or any other phase of development where the job of testing might be affected.
A professional tester will involve her/himself in all phases, not such much to “help” others do their job, but to assure that s/he will be able to do a professional job of testing. So, for example, in the requirements work, the tester should obviously monitor any requirements to ensure that s/he can test to see if they’re fulfilled. The tester should block any vague statements such as “user-friendly” or “efficient” or “fast”—to take just one example.
Moreover, requirements are “gathered” in many ways besides an official requirements gathering phase, so the tester must always be on the alert for any way requirments can creep into the project. For instance, developers frequently make assumptions based on their own convenience or preferences, and such assumptions are not usually documented. Or, salespeople make promises to important customers, or put promises in advertisements, so a tester must spend some time speaking (at least informally) to customers—and also reading ads.
In short, a tester must be involved right from the very first moment a project is imagined, with eyes, ears, and, yes, nose always on the alert for what must be tested, how it must be tested, and whether or not in can actualliy be tested. That's the way a tester "helps" the requirements gathering and all other phases of a project's life, on alert for anything that could affect accurately documenting the state of the system.
As a consequence of this broad view of the tester's job, a tester has to resist any assertion that "you don't have to be involved in this phase," regardless of what phase it is. Obstacles to testing can arise anywhere.
Refer to Exploring Requirements Series
I agree, and I'd like to offer a refinement. Karl Wiegers suggested "if you call it 'requirements gathering', you're doing it wrong." Inspired by Karl, for several years I've been referring to requirements development.
ReplyDeleteI believe that reframes the task in a helpful light. Moreover, since anything that is developed is probably worthy of being tested, helps to emphasizes the importance of testerly thinking from the earliest stage of product development.
---Michael B.
I really like the title exploring requirements, also Michael's suggestion developing requirements. Based on my recent experience, when they gathered requirements all right, but they didn't mention how the combination of the new features is expected to work, I would offer refining requirements.
ReplyDelete@diaflonew
I really like the title exploring requirements, also Michael's suggestion developing requirements. Based on my recent experience, when they gathered requirements all right, but they didn't mention how the combination of the new features is expected to work, I would offer refining requirements.
ReplyDelete@diaflonew
Yes, Obviously a tester should test according to the business requirements.
ReplyDelete