Acceptance Testing Guidance

A few years ago, I met Grigori Melnik at a workshop for software professionals interested in learning new ways to teach testing. He was a programmer and a professor at the University of Calgary, and his presentation was titled “Test Infecting Your Developers.”

I liked him even before I heard him speak because he seemed to be interested in encouraging developers to understand and think more like testers. His presentation included a demonstration of the quirk of notepad that misinterprets the string “this app can break” as a two-byte Unicode text file when it is closed. (There’s even a wikipedia article about this.)

Four years later, Grigori is still at it- trying to “test infect” the people he works with at the Patterns and Practices Team at Microsoft to create meaningful ideasthat help software professionals around the world.

I’m pleased to be working directly with him on a project that’s dedicated to helping developers, testers, managers, and customers prepare for acceptance testing, which we define as “planned evaluation by a customer (or proxy) to determine whether a system satisfies their expectations.”

The topics we plan to focus on include:

– test objectives and strategy,

– the notion of “readiness” as well as “acceptance,”

– defining and reconciling “good-enough” criteria in various industrial contexts,

– working with customers and customer-proxies,

– supporting stories/requirements with acceptance tests.

Our aim is to create guidance artifacts, like case studies and exercises from the real world. As we do that, we’re taking an Agile approach consisting of weekly iterations, standup meetings, backlogs, story cards, personas, and interviews. I’m also keeping a “Dogfood Diary” to show how we anticipate acceptance of the work we produce (that is, “eating our own dogfood”).

On behalf of Grigori, myself, Michael Puleio, and Rohit Sharma, we welcome your comments and thoughts on any aspects of acceptance testing that you would like to comment on (especially if it’s with respect to a project pain point you are encountering).

If you have an interesting experience with acceptance testing that you’d like to share and perhaps be profiled in our guide as a case study, we’d like to hear about it!

Grigori’s blog