Story Time

How many different stories do you know about your product? Do you know the stories your best customer tells? The ones your worst customer tells? Your management? Help Desk? How much of your time do you spend inventing new stories, versus discovering stories of which you had not previously been aware, versus rereading and retelling all those stories you already know?

Looking at the same product, the same broken features, the same "Oh, that doesn't work, you have to do it this way" workarounds day after day, we often become inured to problems and stuck in a rut of always doing the same things the same way with the same data. Our customers, however, generally do not spend their time in these ruts. The people who use our software generally do so as one part of accomplishing something else. Tech support uses our product in order to help people get unstuck when our product gets in their way rather than helping them like they expected. Our management uses our application and the information we provide about it to decide whether to ship our application or hold it back for more work. Their stories are almost certainly not the same as are your stories. Unless you are particularly out of touch, some stories probably match. Many others, however, do not.

Part of our job as testers, it seems to me, is ensuring maximal overlap between the stories we tell and the stories our customers tell. The best way I know to do this is to go find my customers and talk with them. Talk with my management team to learn what information is useful to them and what information is not. Talk with my support technicians to understand what problems my customers are having with my product, and also to understand what problems they are having supporting and diagnosing problems with my product. Sit in with said personnel on product support calls to listen to and speak with my customers directly. Visit my end users in their turf to understand and observe how they are using my product.

If I get through all this without learning any new stories, then I am a happy camper. (Or, possibly, a poor observer - do I really know every possible story?) If I finish all this having learned many new stories, then I am also a happy camper. (Also, possibly, a poor observer - how many stories did I miss?) Either way, my testing is better informed.

How many different stories do you know about your product? How do you go about learning more? Let me know!

*** Want a fun job on a great team? I need a tester! Interested? Let's talk: Michael dot J dot Hunter at microsoft dot com. Great testing and coding skills required.

Comments

• Anonymous
  December 11, 2008
  I can see the value in this.  However any thoughts as to how this would apply to someone like me who is performance testing a completely different piece of software every few weeks?  It might be anywhere from 1 year to 4 years before I see the same piece of software come back for regression or new technology performance testing. Thanks!