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.  
Product Owner and automated tests
tdd;bdd;product owner;tests
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?The Product Owner (or whoever is wearing the Product Owner hat at the time) is acting in a non-technical capacity. They are simply representing the customer and users of the product. They care nothing about how the process works, they are just responsible for developing, prioritizing, and accepting stories.If your Product Owner is also a developer (which is possible - that paring is not one of the ones that is advised against), then perhaps the best task for them would be to serve as the developer of the test cases. If they aren't a developer, work with them to see what they want. Someone with no development experience wouldn't get value out of seeing the implementation of the test cases.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?This is the difference between verification (your automated tests) and validation (acceptance tests and other tests/reviews conducted by the Product Owner).The fact that you have test cases to verify the user story is good. However, it's up to the Product Owner to actually validate the implementation. Saying that your test passes is only good enough to say we have implemented the story as we understand it, not enough to say the implementation of this story meets the needs of the customer and the users. The Product Owner should perform additional acceptance testing on the application to validate the story and its implementation.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.I'm just going to be straight on this one - those aren't good user stories. The whole point of a user story is to explain how the user will interact with a system. You might develop internal stories to break down a user story, and those might be headless. But you'll know that you have completed those based on your passing internal tests and the larger user story passing acceptance testing.