JBehave is Java based & good for Java applications. JBehave also supports good HTML reporting. However, the problem with JBehave is that it only supports Story level and not Feature level.
Can any one here help me with a small explanation or documentation where I can understand how Cucumber supports Feature level?
A feature is an implementation of a capability (a capability might need more than one feature).
Let's look at Mike Cohn's description of a "story", since it's pretty good:
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a <type of user>, I want <some goal> so that <some reason>.
A good user story follows the INVEST principles, and this is where we start getting into scenarios:
A story may have one or more contexts in which the feature is going to work. The contexts are by their nature independent of other contexts.
As you work through a story, you may find other contexts or outcomes that need to be considered. The capability which is the core of the feature is usually associated with the "when". For instance, if I wanted to be able to generate a report, the "when" would be, "When I generate the report..."
There may be several stakeholders with different outcomes. For instance, sending an email to say that a cab's been booked is important, but so is sending the booking confirmation to the driver! By considering different stakeholders, we come up with the outcomes for the scenarios that need to be considered.
If you can't estimate the size, try just getting one scenario working. This is the functional equivalent of Kent Beck's "spike". Incidentally the only reason you need an estimate is usually to work out whether it's worth doing, given other work that could be done, so treat this accordingly.
I actually prefer people knowing they have some level of uncertainty about it, and look to get feedback ASAP. If you're really certain about it (eg: login) then it's OK for it to be bigger, because you'll need feedback less frequently; you know what "working" looks like.
Examples become tests as a nice by-product of this analysis.
Why do we do stories in the first place, though? Why not just deliver whole features?
It turns out that the work needed to get some features shipped ends up being pretty big, especially if you've got a lot of stakeholders involved, and we want to either slice them up so we can get value from them earlier, or we want to slice them so we can get feedback.
So a story might be a slice through a feature that can actually be shipped, or it might be something designed to get feedback.
Scenarios are a fantastic way of doing this! The feature can be narrowed down to the most valuable contexts, or different stakeholders whose outcomes need to be considered. Be careful not to eliminate stakeholders with transactional needs (the user at the ATM gets their money; the bank debits the account) or regulatory needs (the bank makes a major investment; the regulators see the change in capital reserves).
Scenarios aren't the only way of getting feedback on a feature. New UI? Hard-code it without any behaviour and show it to people. New report? Make up a mock copy. New feed that nobody's ever processed? Make a spike, see if you can get the information out of it that you think you can.
Otherwise, consider different contexts and stakeholders whose outcomes need to be considered, and consider different capabilities with their contexts and outcomes. Features implement the different requirements, whose behaviour is illustrated by the scenarios you've derived.
Since a story is a slice through a feature, and a feature implements a capability, this is a typical hierarchy:
If you're trying to work out how to relate scenarios to stories and features, this isn't a bad way to go. You'll find it familiar if you look at Gojko Adzic's "Impact Mapping" or Matt Wynne's "Example Mapping" (I think we all got it from listening to Chris Matts).
Be careful because in reality this is a bit fuzzy; you'll make discoveries as you start to deliver, so don't break everything down ahead of time. I find capabilities make good planning-level artifacts, and are often associated pretty easily with "Epics". They also come with their own high-level tests: "Can our users do what they need to, for the contexts we need to consider, and the stakeholders whose outcomes are also needed?"
The trick with a story is to only consider what's needed to deliver value, until it's actually delivered... and then some of the rest will be the next thing that's needed, etc.
For more ideas, here's my blog on capability-based planning and lightweight analysis, and another one on splitting up stories.
For Cucumber, organize by capability and then (if you need to) by context, and tag your check-ins with the story number (most CI tools, electronic boards and version control systems support this). It's OK for a feature or story to create more scenarios.
