BDD X ATDD X SBE

[Bruno Vieira]

Hello everyone,

I'm knew in QA world, and I constantly listen about Behavior Driven Development (BDD) as a Testing process, 

otherwise I've heard people talk about Acceptance Test Driven Development (ATDD) as a acceptance Test process. 

And the Specification by Example? Is this a complete specification and development process?

Please help me clarify the diference between this 3 terms.

Thank you!

[George Dinwiddie]

I like Liz Keogh's explanation: they're spelled differently.

- George

> --
> You received this message because you are subscribed to the Google
> Groups "Behaviour Driven Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to behaviordrivendeve...@googlegroups.com
> <mailto:behaviordrivendeve...@googlegroups.com>.
> To post to this group, send email to
> behaviordriv...@googlegroups.com
> <mailto:behaviordriv...@googlegroups.com>.
> Visit this group at
> https://groups.google.com/group/behaviordrivendevelopment.
> For more options, visit https://groups.google.com/d/optout.

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

[Liz Keogh]

Thanks George! Yep, pretty much.

ATDD, and Spec by Example, are also intended to do what BDD does, so it's really just in the naming. Having said that, I've found it useful lately to clarify some differences between how I use it, and where (and the naming suits what I do better). Dan North named it so obviously gets credit.

I define three different types of problem, and use a 5-point scale to clarify it:

5: Nobody in the world has ever done it before

4: Someone in the world has done it, but not here.

Both of these are high-discovery, highly uncertain areas. Even if someone else has done it in the world, you don't know what they already had in their culture or resources that helped them to succeed. It might not work for you at all! The trick here is to minimize the amount of time and effort you invest before getting feedback. Conversations are everything. If you're talking about the right kind of scenarios, you'll probably have conversations around some stuff that's irrelevant, and some conflicting ideas, and you'll throw things away.

Because you're minimizing effort before getting feedback, you'll be spiking and prototyping here, rather than fleshing everything out. Learning is the constraint.

I call this "Exploration by Example". Having the conversations is the most important thing.

3: Someone in our organization has done it (or we have other access to expertise)

This is perfect "classic BDD" territory, and a lot of software development falls into this space. Have conversations with people who understand the problem, see if you can capture their expertise, and ask them for lots and lots of examples so that you really understand what they're talking about. These are problems which have already been solved. You're avoiding the expense of having to solve them again by leveraging what other people understand.

This is Specification by Example. You'll also want to make sure you write down the things you learn. Note that the lines between these are blurred; problems which are poorly understood become things around which we have some experience, once we get them working.

We can then also Test by Example. We want to capture that knowledge at whatever scale is appropriate. Examples of how a system, or an API, or a class behaves provide us with end-to-end tests, or integration tests, or class-level unit tests, and you can probably imagine the other kind of tests you might want.

Here, expertise is your constraint.

All of these are still driven by conversations.

(I'm not going to go into the Test Pyramid here but please look it up if you haven't come across it.)

2: Someone in the team has done it

1: We all know how to do it

This is the really boring stuff that's well-understood. Talking through the scenarios at this stage is overkill. I normally suggest just writing down the titles. Dan likes to call them "The one where..." like Friends episodes, so for instance:

The one where we create a user

The one where we delete a user

The one where we update a user

If what you're doing is as simple as a Web CRUD form, this is all you need. You might like to talk about some different things like the lengths of fields etc.. This should be based on really solid experience. These kind of requirements rarely change, so it might even be enough to test them manually when you change them, then leave them alone. Ideally you'll be using something off-the-shelf anyway, and if you do have to code it yourself, try to make that capability reusable. Get it into its own library or service and out of your build. And consider open-sourcing it if there isn't one already!

Here, production is your constraint. You just want to get it working quickly and to avoid doing it again next time.

(Credit to Julian Birkenshaw of the London School of Economics, and his "Adhocracy" model, for inspiration for the constraints.)

However... people build on the well-understood, commoditized stuff... producing another innovative thing that isn't well understood.

What we do in software development is always new. We're always trying to let people, or systems, do something they couldn't do before, or in a way they couldn't do it before, or in a new context. So we're always driven by a 4 or 5 (even if there are bigger parts of our problem)! Those bits of what we do are the most valuable, and also the most risky (being high-discovery spaces), of our requirements. So we want to do those first, rather than committing a bunch of other stuff towards them, because they might not work.

So to summarize, there are three aspects of BDD:

Exploration by example (having the conversations), which is more important than

Specification by example (capturing the conversations), which is more important than

Test by example (automating the conversations).

So, if you can identify which bits are new, start with those.

Now it's a complete development process. Mostly. It doesn't all fit in one post. But hopefully this helps.

Cheers,

Liz.

On Fri, Jul 6, 2018 at 3:31 PM, George Dinwiddie <li...@idiacomputing.com> wrote:

I like Liz Keogh's explanation: they're spelled differently.

 - George

On 7/6/18 9:57 AM, Bruno Vieira wrote:

Hello everyone,

I'm knew in QA world, and I constantly listen about Behavior Driven Development (BDD) as a Testing process,
otherwise I've heard people talk about Acceptance Test Driven Development (ATDD) as a acceptance Test process.
And the Specification by Example? Is this a complete specification and development process?

Please help me clarify the diference between this 3 terms.

Thank you!

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsubsc...@googlegroups.com <mailto:behaviordrivendevelopment+unsubscribe@googlegroups.com>.
To post to this group, send email to behaviordrivendevelopment@googlegroups.com <mailto:behaviordrivendevelopme...@googlegroups.com>.

Visit this group at https://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

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

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.

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

Visit this group at https://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

--

Liz Keogh
l...@lunivore.com
http://lizkeogh.com
http://lunivore.com

[Bruno Vieira]

Liz keogh,

Many thanks for your explanation, it was very usefull for me.

I am reading the book "Specification by Example" by Gojko Adzic, and I'm thingk it's gonna make tha things clear.

Thank you again. you helped me a lot. 

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com <mailto:behaviordrivendevelopment+unsubscribe@googlegroups.com>.
To post to this group, send email to behaviordriv...@googlegroups.com <mailto:behaviordrivendevelopme...@googlegroups.com>.

Visit this group at https://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

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

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.

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

Visit this group at https://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.