5

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.

Improve this question

2 Answers 2

Reset to default
3

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.

Improve this answer
2

Working a Feature and Sign off

At my work when a developer picks up a new piece of work the first thing they do is identify who the "Owner". They then go to them have a quick discussion on their understanding of the problem and what the intended solution will be.

Once the developer has finished the implementation they then go back to the "Owner" for sign off. Sign off involves the developer showing the implementation in a working system (their dev system) with reasonable data. If the "Owner" is satisfied they sign off and the implementation is complete. If the "Owner" is not satisfied the developer identifies what changes needs to occur. He then implements those and tries for sign off again.

Improve this answer
3
  • BTW, what you call "sign off" is just what happens during the "Review" in Scrum.
    – sleske
    Sep 6, 2011 at 9:50
  • It's slightly different though because it only involves the "Owner" and the developer, and it's done for every feature as they are completed.
    – snakehiss
    Sep 6, 2011 at 19:25
  • True. In Scrum, the review is also meant to cover every feature, but in one session (usually). However, it involves everyone, not just the "owner".
    – sleske
    Sep 7, 2011 at 7:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.