Re^2: Behavior Driven Development: suggested tools for perl?

BDD isn't a replacement for decent testing at all. We use the scenarios to facilitate conversation, to ensure that the software we're writing is software that matters. Sometimes those scenarios can help the invaluable, irreplaceable QAs (but I've done them manually before, in the absence of a decent automation tool).

We also identify stakeholders, rather than just users. If long-term stability, performance or security is important, there's probably a stakeholder who can define what that means, and how to tell if you've achieved it; they'd be the people we had that conversation with. Captchas are the example I use most frequently - users don't want them and won't care if they produce false positives.

-- Liz.

Comment on Re^2: Behavior Driven Development: suggested tools for perl?

Replies are listed 'Best First'.
Re^3: Behavior Driven Development: suggested tools for perl? (Stakeholders) by ELISHEVA (Prior) on Apr 03, 2009 at 13:12 UTC
there's probably a stakeholder who can define what that means Indeed. As you know whenever something becomes a buzzword, it also becomes oversimplified. On the other hand, I question whether one is really doing BDD if one have broadened it to the general (non BDD specific) wisdom: listen to your stakeholders and agree upon measurable deliverables. The conversational tools of BDD are not necessarily the best communication method for all stakeholders. End users often respond well to stories because they experience their jobs as a flow. BDD can be an extremely effective tool for communication with this group of stakeholders. On the other hand, senior management tends to respond better to discussions that focus on cost-benefit analysis: the cost of implementing X versus the impact of X on market position, future sales, branding, and other strategic or operational goals. Stories (aside from case studies of market success or failure) tend to take the back stage. IT managers and the engineering staff who advise them are primarily interested in fact-based discussions of the impact of implementation X vs. Y on total cost of ownership (TOC), long term support needs and security related liabilities. Connecting the dots between the technical features of implementation X and the TOC of implementation X takes a lot more than getting stakeholders to articulate goals and scenarios. I find it far more important to do an assessment of organizational strengths and coping mechanisms. TOC does not exist in a vacuum - it is inseparable from organizational culture. I suppose you could call market impact, TOC or security risk level a "behavior", but if you do so, you've broadened the meaning of BDD so greatly that (a) behavior merely becomes a synonym for goals (b) BDD looses its distinctiveness as a methodology. Best, beth	[reply]

Replies are listed 'Best First'.

Re^3: Behavior Driven Development: suggested tools for perl? (Stakeholders)
by ELISHEVA (Prior) on Apr 03, 2009 at 13:12 UTC

there's probably a stakeholder who can define what that means

Indeed. As you know whenever something becomes a buzzword, it also becomes oversimplified. On the other hand, I question whether one is really doing BDD if one have broadened it to the general (non BDD specific) wisdom: listen to your stakeholders and agree upon measurable deliverables.

The conversational tools of BDD are not necessarily the best communication method for all stakeholders. End users often respond well to stories because they experience their jobs as a flow. BDD can be an extremely effective tool for communication with this group of stakeholders.

On the other hand, senior management tends to respond better to discussions that focus on cost-benefit analysis: the cost of implementing X versus the impact of X on market position, future sales, branding, and other strategic or operational goals. Stories (aside from case studies of market success or failure) tend to take the back stage.

IT managers and the engineering staff who advise them are primarily interested in fact-based discussions of the impact of implementation X vs. Y on total cost of ownership (TOC), long term support needs and security related liabilities. Connecting the dots between the technical features of implementation X and the TOC of implementation X takes a lot more than getting stakeholders to articulate goals and scenarios. I find it far more important to do an assessment of organizational strengths and coping mechanisms. TOC does not exist in a vacuum - it is inseparable from organizational culture.

I suppose you could call market impact, TOC or security risk level a "behavior", but if you do so, you've broadened the meaning of BDD so greatly that (a) behavior merely becomes a synonym for goals (b) BDD looses its distinctiveness as a methodology.

Best, beth

[reply]