Jim Drew wrote:
> On my current project, our initial black box test plans were informed > by very early mockups done for "what features would you want in this > product" surveys. We didn't have semi-valid mockups (or text specs) > of the real stuff for months. As a result, our initial test plans > were based on our guesses of what the product would do from those > invalid pieces of info, and we ended up having to fight those > assumptions back later on. > > We wasted time and the mental effort needed to comprehend the product > because the info we were given was invalid, and known to be so, but > its invalidity was not transmitted to us. (Once burned, twice shy, > though. We'll know better next time. Maybe.)
***In the rush to market that's so common these days, these sorts of things
often happen. It's really important to lay your foundations before trying to
> > > discussion of expected feature > > > interactions and user workflows > >***PGP Yes. I call the latter usage scenarios. They document user > >interactions step by step. > > They seem to be the hardest things to get into the specs. They tend > to live in marketing documents rather than engineering specs, but not > in MRDs or other docs which are available to the entire team. > Workflow info on the current project has had to be guessed at based > on incomplete knowledge of semi-competing products. Thank god for > the marketing and QE people both being in the UI spec reviews, or > some of that info would never get from them to us, and we're the ones > who have to test what they want the product to do!
***I must admit that under schedule constraints, this is sometimes a part of
a spec that gets sacrificed, but I know the value that it provides to both
QEs and technical writers.