Elevator pitch?

[Thomas Sundberg]

Hi!

What is your elevator pitch for BDD and Cucumber?

/Thomas

Elevator pitch: A 10 seconds sales pitch that you can deliver during
an elevator ride that describes an idea in such a way that an
executive can understand it.

--
Thomas Sundberg
M. Sc. in Computer Science

Mobile: +46 70 767 33 15
Blog: http://www.thinkcode.se/blog
Twitter: @thomassundberg

Better software through faster feedback

[George Dinwiddie]

Begin with the end in mind. It's hard to get the desired outcome if not
everyone has the same outcome in mind. BDD is a means of agreeing on
that outcome in sufficient detail to create working software. Cucumber
allows you to turn that agreement into regression tests.

- George

On 4/29/17 2:49 AM, Thomas Sundberg wrote:
> Hi!
>
> What is your elevator pitch for BDD and Cucumber?
>
> /Thomas
>
> Elevator pitch: A 10 seconds sales pitch that you can deliver during
> an elevator ride that describes an idea in such a way that an
> executive can understand it.
>

--

----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Thomas Sundberg]

On 29 April 2017 at 11:40, George Dinwiddie <li...@idiacomputing.com> wrote:
>
> Begin with the end in mind. It's hard to get the desired outcome if not
> everyone has the same outcome in mind. BDD is a means of agreeing on that
> outcome in sufficient detail to create working software. Cucumber allows you
> to turn that agreement into regression tests.
>

Thanks George!

I came with an alternative after some fiddling.

"Behaviour-Driven Development, BDD, is a way to collaboratively
specify software that says what it does and does what it says.
The specifications are readable and executable.
When they are successfully executed, the software works as wanted."

Having a few options is good so I will keep both.

/Thomas

> - George
>
> On 4/29/17 2:49 AM, Thomas Sundberg wrote:
>>
>> Hi!
>>
>> What is your elevator pitch for BDD and Cucumber?
>>
>> /Thomas
>>
>> Elevator pitch: A 10 seconds sales pitch that you can deliver during
>> an elevator ride that describes an idea in such a way that an
>> executive can understand it.
>>
>
> --
> ----------------------------------------------------------------------
> * George Dinwiddie * http://blog.gdinwiddie.com
> Software Development http://www.idiacomputing.com
> Consultant and Coach http://www.agilemaryland.org
> ----------------------------------------------------------------------
>

> --
> Posting rules: http://cukes.info/posting-rules.html
> --- You received this message because you are subscribed to the Google
> Groups "Cukes" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cukes+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Andrew Premdas]

"Behaviour-Driven Development, BDD, is a way to collaboratively
specify software that says what it does and does what it says.
The specifications are readable and executable.
When they are successfully executed, the software works as wanted

I'd replace 'specify' with 'build', and perhaps 'The specifications' with 'We create specifications that are ...'

Finally although I quite like the last line, it is IMO quite misleading. The successful execution of specifications guarantee nothing much at all without review. Its the quality of the review process in tandem with the specifications that give you a better chance of getting the software you want. Getting that across in an elevator pitch is an entirely different challenge.

All best

Andrew

> email to cukes+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
Thomas Sundberg
M. Sc. in Computer Science

Mobile: +46 70 767 33 15
Blog: http://www.thinkcode.se/blog
Twitter: @thomassundberg

Better software through faster feedback

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cukes+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

------------------------

Andrew Premdas

blog.andrew.premdas.org

[Thomas Sundberg]

On 9 May 2017 at 12:16, Andrew Premdas <apre...@gmail.com> wrote:
> "Behaviour-Driven Development, BDD, is a way to collaboratively
> specify software that says what it does and does what it says.
> The specifications are readable and executable.
> When they are successfully executed, the software works as wanted
>
> I'd replace 'specify' with 'build', and perhaps 'The specifications' with
> 'We create specifications that are ...'
>
> Finally although I quite like the last line, it is IMO quite misleading. The
> successful execution of specifications guarantee nothing much at all without
> review. Its the quality of the review process in tandem with the
> specifications that give you a better chance of getting the software you
> want. Getting that across in an elevator pitch is an entirely different
> challenge.
>

Yep, getting something important and sometthing sometimes considered
complicated across as an elevator pitch is a challenge.

Thanks for your feeback!
Thomas

>> > email to cukes+un...@googlegroups.com.

>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Thomas Sundberg
>> M. Sc. in Computer Science
>>
>> Mobile: +46 70 767 33 15
>> Blog: http://www.thinkcode.se/blog
>> Twitter: @thomassundberg
>>
>> Better software through faster feedback
>>
>> --
>> Posting rules: http://cukes.info/posting-rules.html
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Cukes" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to cukes+un...@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> ------------------------
> Andrew Premdas
> blog.andrew.premdas.org
>

> --
> Posting rules: http://cukes.info/posting-rules.html
> ---
> You received this message because you are subscribed to the Google Groups
> "Cukes" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to cukes+un...@googlegroups.com.

[80Vikram]

From my experiences as QA who is following BDD since last 10 month

"BDD avoid You Burn, I'll Scrape culture within company".

Regards,
Vikram

[Roberto Lo Giacco]

Il giorno sabato 29 aprile 2017 08:49:42 UTC+2, Thomas Sundberg ha scritto:

Hi!

What is your elevator pitch for BDD and Cucumber?

I didn't have one, but your question made me think about it and I now strongly believe I need one.

Compared to what others have written I believe I needed something less technical and more "money oriented" as the managers I generally deal with are biased versus money and saving... 

"It's a better way to create software requirements: rather than using a business analyst to translate the business needs into requirements we ask the business representative(s) and the developer(s) to agree on a terminology and communicate directly with a medium-term time-saving on requirements and overall software stability improvement. The toughest part is to deliver THIS message to the parties."

[80Vikram]

I would like to suggest small correction in this "....business representative(s) , QA &  the developer(s)...."

Good QA can catch bugs at requirement discussion phase itself and avoid You Burn and I Scrape situation.

Let me know your thoughts.

I'm trying really hard to implement BDD in my current startup but I find it hard to convince some developers and management as well.

As they ( management ) feel customers can find bugs and we can fix later. Developer thinks s/he is GOD and can't do any mistakes in each and every sprint.
In my last 15 years of QA career didn't see any developer who delivers bugs free s/w each release, that's why even companies like Apple and Google has dedicated QA teams.

I was with Y! and MS and seen how their quality of deliverable degraded after getting rid of QA team altogether.

Regards,
Vikram

[Roberto Lo Giacco]

Il giorno giovedì 18 maggio 2017 10:57:40 UTC+2, 80Vikram ha scritto:

I would like to suggest small correction in this "....business representative(s) , QA &  the developer(s)...."

Good QA can catch bugs at requirement discussion phase itself and avoid You Burn and I Scrape situation.

Let me know your thoughts.

If there is something I managed to communicate upwards into my chain of command is there is no distinction between QAs and DEVs. Effectiveness of such communication is probably due to the obvious consequence they think they are now saving on testing, which is kinda true considering testing is now part of development and the overall increase in quality :)

 

I'm trying really hard to implement BDD in my current startup but I find it hard to convince some developers and management as well.

As they ( management ) feel customers can find bugs and we can fix later. Developer thinks s/he is GOD and can't do any mistakes in each and every sprint.
In my last 15 years of QA career didn't see any developer who delivers bugs free s/w each release, that's why even companies like Apple and Google has dedicated QA teams.

My hook with developers has been "wouldn't be better to know your mistakes a few minutes after you have done them, when you still have the problem fresh in your mind?" Whenever any of them says they don't do mistakes I simply smack him/her in the face as hard as I'm able to.

With management it has been just a matter of costs: I promised I can increase quality without increasing costs per se. I didn't even try to dig into "you spend a little bit more now in favor of a better ROI" :D

[80Vikram]

 :)

I wish ( & pray ) all the developers and management think like you.

Regards,
Vikram

[Joaquin Menchaca]

BDD test the feature results, not implementation, which changes all the time.  Thus high value-add for BDD, less on activities to maintain tests that don't directly contribute to revenue.

Cucumber is system that uses a language in plain English text that product managers, QA, and engineers can understand.  With this, you can have discussions to iron out the requirements.  This reduces surprises and bugs in implementation before the tests are even run.

[Roberto Lo Giacco]

Il giorno martedì 13 giugno 2017 23:38:58 UTC+2, Joaquin Menchaca ha scritto:

BDD test the feature results, not implementation, which changes all the time.  Thus high value-add for BDD, less on activities to maintain tests that don't directly contribute to revenue.

I don't think any in my management chain would understand this sentence...

 

Cucumber is system that uses a language in plain English text that product managers, QA, and engineers can understand.  With this, you can have discussions to iron out the requirements.  This reduces surprises and bugs in implementation before the tests are even run.

This one instead might actually be effective on some of my management: well done! 

[Aaron H]

Personally think it is important to focus on Behavior Driven Development as a holistic development process that creates a common ubiquitous language between technical and non-technical users on a project.

[Roberto Lo Giacco]

On Wed, Jun 14, 2017 at 2:27 PM, Aaron H <aaronjh...@gmail.com> wrote:

Personally think it is important to focus on Behavior Driven Development as a holistic development process that creates a common ubiquitous language between technical and non-technical users on a project.

Maybe it's the people I have to deal with, but the above uses a language which is going to scare most of them... "holistic" and "ubiquitous" are two non obvious terms....

[Aaron H]

Another point that might work well as part of this type of a pitch is that cucumber based tools allow teams to think about test design before any implementation code is written. Collaboratively authoring the Gherkin scenarios as a first step helps ensure the scenario is effective, prevent implementation code duplication, etc.

[Marit van Dijk]

My experience is that writing the scenarios & examples triggers us to think of different cases and how the system should behave _before_ it is built, allowing for discussion with Product Owner / Business Analist / QA / Dev before (or while) features are being built. This causes less rework than getting the business feedback _after_ (a version of) the feature has been built. Also, writing the features in "plain" language helps facilitate discussion and common understanding.

Main selling point to me are:
1. common understanding up front!
2. executable specs - the documentation is part of the code base
If the tests pass, then for sure this is how the system works (yes, the tests have been reviewed and also I write them as the features are being built: red-green-refactor)
vs having no documentation or having documentation but not knowing how up to date it is
3. Test automation
Automated tests allowing (relatively) quick check of different cases (vs having to manually set up all different cases in various systems/services with test data)
Also less error-prone than repetitive manual work.

[Andrew Premdas]

I think the phrase 'thinking about how the system behaves before it is built' is perhaps misleading.  Instead I'd suggest that BBD helps you think about what the system does and why its important.

There is a big difference between the What/Why and the How

What are your thoughts on this?

All best

Andrew

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cukes+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Roberto Lo Giacco]

On Thu, Sep 7, 2017 at 11:48 PM, Andrew Premdas <apre...@gmail.com> wrote:

I think the phrase 'thinking about how the system behaves before it is built' is perhaps misleading.  Instead I'd suggest that BBD helps you think about what the system does and why its important.

There is a big difference between the What/Why and the How

What are your thoughts on this?

​I'm personally 100% with you Andrew. Especially on the "why it's important": too often we develop unused or unncessary features.​

Mail priva di virus. www.avg.com