Depending on who's asking, what they're asking for, and the kind of project they're working on, we'll ask for different levels of specificity in the input they give us. For example:
- a one-time, ad hoc project to gather some performance data from a trial server might require no more than an email confirming the test envelope and environment and an idea of the intent of the experiment
- a three-month R&D project which delivers scripts to a partner might have a brief description of the aims, the high-level requirements and any areas which were not addressed
- a brand new software feature would come with some kind of software requirements specification and we'd expect the QA team to be involved in the development of that before implementation proper began.
Different customers also have different expectations of the way that reports are delivered to them. For example, marketing folk might be comfortable with a Word version of their press release marked up with comments. The dev team might prefer to receive their defect landslide as issues in our bug tracking system.
We try to provide templates/checklists on our wiki for the most common kinds of interactions so that customers learn (or can look up) what we expect as input for a particular piece of work, what kind of coverage we'll provide, and what we'll deliver as output. Sometimes these won't fit and in those cases we offer advice on what might work but have to be prepared to be flexible to what the customer needs.
Like tailors, even though we have the eye, the expertise, the tape measure and the scissors, in the end it's the customer that wants to wear it and so we have to cut our cloth to suit.
Image: http://flic.kr/p/5XT9C under Creative Commons