Like Pearson said, its pretty key IMHO that whatever the BA's are working on/outputting is the live test case, which lives in the codebase.
If the BAs maintain their own separate(read: not in SC) requirements system/documents, no matter how well everyone sits down together and translates them into cukes, the 'in code' cukes will diverge from the BA docs over time. This can be because the feature evolves over time, or the devs take liberties in restructuring the cuke to fit with the steps they already have(ive never done this.... <.< >.>). End result, you'll end up with two 'sources of truth' that dont match up, and headaches ensure. In a disagreement the BA's retreat to their castle accusing the devs of altering the features, and vice verse for devs, neither has faith in the others system, not good. I've setup systems before for less technical BAs that used check-in hooks to publish the features to a fileshare, with some basic structure: /backlog <- read/write by BA's, not in SC. This is where BAs can draft features pre kickoff. /wip <- read only, exported from SC using a grep for @wip, so the BAs can see whats being worked on. /finalized <- read only, exported from SC (excluding @wip). Acts as a reference. Devs & BAs sit down at kickoff, review the backlog features, tidy them up a bit and commit them to SC with @wip. All changes to accepted features need to be either raised with devs, or maybe you might let BAs edit @wipped features, up to you. However, if the BAs are flat out not interested in contributing/ maintaining features, then perhaps consider not using cucumber. If no 'businessesy' people are going to read the features, and its only going to be devs doing the requirements -> test code translation, then the overhead involved in achieving the readability of cucumber might not be worth it. Still write full stack features, just peel off the top level of abstraction and use something like capyabara integrations. No need to maintain the english->code translation layer if noone's going to read the english :p. On Oct 13, 12:23 pm, Michael Pearson <[email protected]> wrote: > They weren't at the start. By the end of it they knew enough about git to > perform the basic commit/pull/push process. > > Not a much bigger ask than making sure their formatting when editing / > tagging cukes is consistent and honouring the Given/When/Then format. > > On Thu, Oct 13, 2011 at 12:20 PM, Dmytrii Nagirniak <[email protected]>wrote: > > > > > > > > > > > > > > AFAIR, we ended up with BAs writing cukes, marking them as @wip and > > committing them to git for later use. > > > Your BAs are geeks if they can commit to git :) > > Or you've provided some infrastructure for them? > > > -- > > You received this message because you are subscribed to the Google Groups > > "Ruby or Rails Oceania" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > >http://groups.google.com/group/rails-oceania?hl=en. > > -- > Michael Pearson > The Bon Scotts;http://www.thebonscotts.com -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
