Acceptance tests can be Boundary Objects. In the early days of Agile, acceptance tests (a term used in Extreme Programming) were the objects that programmers, testers, and product owners talked about as a means of coordination.
**Product owners** want acceptance tests to be clear descriptions of what they want, because programmers do a lot better at understanding the general requirement when they’re given specific examples.
**Testers** want acceptance tests because they can use variations of them to demonstrate that neither the programmers nor the product owners are really clear in their minds about what a new feature should do.
**Programmers** want acceptance tests because the product owners are infuriatingly vague about what they want and, when they’re presented with a working feature, keep saying “that’s not really what I meant”. Acceptance tests provide a nice binary pass/fail metric that we can use to say “See! We did what you said.” Now, more enlightened teams know that it’s expected and fine when a product owner’s response to a finished feature is “that’s what I said, but it turns out not to be what I meant”. It’s certainly better than just accepting the wrong feature. But acceptance tests are useful when they make such conversations less frequent.
See this Acceptance Test Story for more.