1

I am involved in a project where Given-When-Then formatted stories are written by the Product Owner (in a web-based story repository / JIRA), then created by Developers, while system test automation (written as SpecFlow .feature files) is built by the Tester to cover all testable behaviours.

What seems to happen as a natural part of the lifecycle is that the test automation logic will combine, extend and clarify the details of the original acceptance criteria. This further definition can be lost, however, since the .feature files are only reviewed by the Tester, while the Product Owner wants only to be exposed to the original set of stories and acceptance criteria.

It seems like we might be breaking BDD by not exposing the .feature files to the Product Owner, but even if the latest .feature files are available through a version control tool, does that mean our Product Owner would need to learn about that as well?

And even if they access these files through version control, how are Product Owners supposed to write useful GWT statements without also using the IDE to discover/intellisense the existing step definitions?

What experiences are others having with this type of situation? Any suggestions are appreciated.

Thanks.

Improve this question

2 Answers 2

Reset to default
1

A lot of your question talks about the tools, Jira, source control, etc. I think you are letting the process that the tools facilitate is guiding your thinking too much.

If you read Liz Keogh, she repeatedly talks about the conversation that you need to have in order to fully define and form your ideas about the feature that you are developing. I think your current process is isolating people too much and preventing the conversation from happening. As you say, the POs are not reviewing the updated specifications, to me, that seems to be because they are being produced in isolation originally. Since the testers requirements aren't met then they update the specifications without the POs being involved either. If you could get all parties involved in a conversation initially then the process

However if you decide to keep your current workflow, there are some features of Jira that might also help you to improve it. See if you can get FishEye added to your Jira installation. This enables you to produce code reviews, which would be a simple means of highlighting the specification changes to your POs and kicking off a conversation about those changes. You could find that some changes only need a few comments electronically, others might require picking up the phone or talking it over face to face, but at least they aren't missed. Just looking at the highlighted changes would certainly be better than opening up the whole source tree to the POs and possibly missing some of those specification changes inside all the other source files.

Improve this answer
1
  • Thanks for the response. I was trying to mention the tools to define my situation more clearly; I realize that the process should define the tools and not vice-versa. :) I think you are right about having more conversations, as the original spec is, in fact, built in isolation. We do use FishEye and we do perform code reviews, however I'm more concerned about the visibility of the altered state of story logic during development. The original stories don't describe things very verbosely, even though they are GWTs. I think the real answer is to collaborate on the original stories. Thanks.
    – Jon T.
    Commented Oct 9, 2013 at 1:26
0

In my situation the clarification process happens working together with the product owners from every involved area. Once the requirements are clarified, reviewed and signed off then I'm going to write the BDDs and basically the BDDs are not reviewed by POs. It is a result of process evolving.

The POs can see that the product represent the business value they wanted, the product is working fine and the testing activity is able to prove the business value exists. Due to that they have the feeling of safety and the trust in the product they think that there is no need to have the BDDs reviewed by them. It is a sign of trust.

On the other hand, they take the BDDs as part of the testing and not part of the whole process. It is due to that the whole BDD methodology was introduced in a bad way and badly managed and there is no company wide education activity.

Improve this answer
1
  • I agree that clarifying story criteria early on should be a part of this. I also understand what you're saying about the absence of a PO review being a sign of trust, but I've always imagined that the purpose behind putting GWTs into .feature files as business-readable logic was to give visibility to the business side (i.e. the PO, legal, etc). Maybe this is where I've made a wrong assumption.
    – Jon T.
    Commented Oct 9, 2013 at 1:53

Your Answer

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

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