One of the claims of BDD-style development is that it bridges the gap between Product Owner and developers: the Product Owner writes a story, which can be converted in an equivalent automated test "frame" that should eventually pass.
What I would like to hear is how to keep bridging the gap after that: once there are automated tests in place, how do you help the Product Owner review them? Or is it enough for the Product Owner to know that the test passes, without looking at the test code itself?
In short, how intimate should the Product Owner be with the actual tests implemented, and how do you keep him/her productively involved with the tests beyond the initial story writing?
The reason behind this question is double. First, between the paper story and the implementation details, some assumptions may sneak in, and having the author of the story review the test can be invaluable. On the other hand, the implementation introduces quite a bit of noise, too, and requires the PO to become fairly technical (read code, run tests). Is the test implementation a "developer's detail", or is it fair to request the PO to become a bit of a developer in this area?
Then, in most case, the PO can actually validate the test without the automated test, by simply using the application. However, some stories are "headless" and can only be verified via code, so unless the PO knows how to read and run tests, he/she will never be able to state that he verified the story complete.