checking two distinct and non-interacting sets of rules. One is the rules
about taxes, and one is the rules about shipping costs. I would divide the
doing anything else.
Post by Andrew PremdasAll best
Nice example, Andrew. I have found that when using tables for
password rules I needed a <reason> column to explain which rule was
being tested. That's a sure sign to me that a different scenario is
beneficial.
I was at a client recently and they were delighted that they could
use Scenario Outlines rather than repeating the scenario. The issue
had to do with different legal requirements in different states. I
don't remember the details, so these made up examples will have to
suffice.
Scenario Outline: State requirements for Spouse as SNI
Given the Primary Named Insured resides in <state>
And the Secondary Named Insured has a relationship of "Spouse"
When the Agent views the policy
Then there is no option to remove the Secondary Named Insured
| state |
| AL |
| AK |
Scenario Outline: No state requirements for Spouse as SNI
Given the Primary Named Insured resides in <state>
And the Secondary Named Insured has a relationship of "Spouse"
When the Agent views the policy
Then the Agent can remove the Secondary Named Insured
| state |
| SC |
| SD |
As I recall, there were other state-oriented scenarios with value
limits, but I can't recall them well enough to generate examples.
I can certainly see how the above could be written as individual
scenarios, but it was both more convenient and less error prone to
implement it with tables.
- George
On 14 September 2017 at 16:57, George Dinwiddie
Andrew,
I'm not exactly sure what you mean by this. Can you give an example
of extracting the spirit/meaning of the examples and naming them?
- George
Sure, lets take something everyone knows about registrations
(excuse bad syntax I don't use outlines examples or tables anymore).
Scenario Outline: Bad registrations
When I register with <account> <password>
Then I should not be register
Account | Password
bad_account | good_password
good_account | 1234
good_account | sdfdsflsdfsdf3313
good_account | wieikjkeiiow
OK so our business peeps have come up with some examples of
account|password combinations that should fail. Now we have to
take each pair and try and extract the spirit/meaning. I'll
start with the easy one
good_account | 1234
This is probably to do with password length. (note all examples
are by their nature ambiguous, this is why scenario outlines and
examples are bad in my book, they don't have information to be
clear about their intention)
So I'd extract a scenario
Scenario: Short password
When I register with a short password
Then I should see my password is to short
The next one is a bit more confusing. Some possibilities are
Need a capital letter
Need a special character
So here I might have to check with the business, and then I'd
rinse and repeat
From this process we end up extracting and making concrete
several important concepts
- short passwords
- passwords with special chars
- passwords without capitals
etc.
Now it might seem a stretch but you can apply this concept to
every scenario outline, and to every example group or table of
examples. And if you do, not only will you get simpler features
that are easier to implement and work with, you'll also get most
of the 'names' you need to write the code to implement the
particular behaviour you are specifiying (yay!)
HTH
Andrew
This ties in quite nicely with my idea/opinion that any Cucumber
scenario that has examples in it, particularly tables is in some
way incomplete.
You complete the scenario by extracting the
spirit/meaning of
the examples and in the process name things. When you have done
this all the tables of examples just disappear and you are left
with named concepts specific to your context.
All best
Andrew
On 14 September 2017 at 10:32, aslak hellesoy
Thanks for the clarification Gabriel.
In the past few years, after helping dozens of
organisations and
hundreds of people adopt BDD I have come to the conclusion
that it
is counter-productive to have 3 amigos (BAs, testers and
programmers) write executable specifications (Gherkin)
together.
What I encourage instead is that they create *examples*
together.
Examples are not executable specifications - they
are simply
conversation topics, often jotted down on a card as a
sketch or a
few words. I recommend Example Mapping
(https://cucumber.io/blog/2015
/12/08/example-mapping-introduction <https://cucumber.io/blog/2015
/12/08/example-mapping-introduction>
<https://cucumber.io/blog/2015/12/08/example-mapping-introduction
<https://cucumber.io/blog/2015/12/08/example-mapping-introduction>>
<https://cucumber.io/blog/2015
/12/08/example-mapping-introduction <https://cucumber.io/blog/2015
/12/08/example-mapping-introduction>
<https://cucumber.io/blog/2015/12/08/example-mapping-introduction
<https://cucumber.io/blog/2015/12/08/example-mapping-introduction>>>)
as a technique to create examples together.
When conversations happen around lo-fi examples
like this in an
example mapping session, stakeholders tend to
uncover a lot of
misunderstandings and gain new insight. In my experience,
this does
not happen when the conversations happen around executable
specifications (Gherkin). Instead, conversations tend to
revolve
around grammar and formulation, diverting the attention
from the
problem domain and the examples themselves. Writing
specifications
together is also slow and tedious, and people
don't enjoy these
sessions as much. When it's not enjoyable, people
stop doing it
pretty quickly. Example Mapping on the other hand is
energising and fun.
BDD is a variant of TDD, where programmers write
code guided by
failing tests. In my experience, this workflow does not
work well
when the specifications were written
collaboratively. When the
programmers starts the red-green-refactor cycle with
collaboratively
written scenarios, they quickly realise they need to
reformulate
those scenarios, for a number of reasons. They're
incomplete,
they're ambiguous etc. When scenarios start passing, the
scenarios
are often very different from what the diverse
group created
together. This often causes frustration: "You've completely
rewritten it - this is not what we wrote together - I don't
understand this".
So instead I recommend programmers write the executable
specifications, perhaps with assistance from a tester. They
use the
example map as input when they do this, and do their best
to capture
the spirit of the examples and the conversations. When
they're done
(or better - while they're doing it), they show the
scenarios to the
BAs/POs and ask for feedback: Do you understand
this? Does it
reflect what we discussed during example mapping? Then they
tweak
Specification, Test and Documentation.
BDD isn't a process where you can write the specification
up-front -
even when it happens collaboratively. They take shape as
you go, in
parallel with development. The only thing you can
do up-front
(before coding) is to reduce the
misunderstandings, but
executable
specifications isn't a good medium for that I think.
Cheers,
Aslak
On Thu, Sep 14, 2017 at 7:18 AM, Gabriel Oliveira
Hi Aslak,
Thanks for pointing this out - this was a mistake on
our part.
The intent was to state that fact that bad requirements
are one
of the many causes of project failures.
Already fixed on bit.ly/bdd_quality
<http://bit.ly/bdd_quality>
<http://bit.ly/bdd_quality> <http://bit.ly/bdd_quality>
On Wed, Sep 13, 2017 at 11:03 PM, Aslak HellesÞy
Hi Gabriel,
"Since it is well known that executable solution
requirements are one of many potential causes of a
project
failure, we come to ask some questions about this
subject."
1) Are you saying that project failure can be
partly caused
by the fact that specifications are executable?
2) After 12 years in this field I've never heard
this - on
what basis are you claiming this is well known?
Cheers,
Aslak
On Thursday, September 7, 2017 at 2:17:45 PM UTC+1,
Gabriel
Hi folks,
Have you been practicing BDD (Behavior-Driven
Development) lately and believe scenarios'
quality matter?
I'm writing my graduate thesis on that subject
and would
like to invite you all to answer a
(really) small 2
https://goo.gl/forms/dheA8XK0asiNUVze2
<https://goo.gl/forms/dheA8XK0asiNUVze2>
<https://goo.gl/forms/dheA8XK0asiNUVze2
<https://goo.gl/forms/dheA8XK0asiNUVze2>>
<https://goo.gl/forms/dheA8XK
0asiNUVze2
<https://goo.gl/forms/dheA8XK0asiNUVze2>
<https://goo.gl/forms/dheA8XK0asiNUVze2
<https://goo.gl/forms/dheA8XK0asiNUVze2>>>
If you're willing to spend a little more time
to talk to
me about that topic, please remember to fill
out your
contact information there - or comment on this
thread
here - and I will promptly get in touch :) !
Best regards,
--
*Gabriel P.A. de Oliveira*
/https://gpaoliveirablog.wordpress.com
<https://gpaoliveirablog.wordpress.com>
<https://gpaoliveirablog.wordpress.com
<https://gpaoliveirablog.wordpress.com>>
<https://gpaoliveirablog.wordpress.com
<https://gpaoliveirablog.wordpress.com>
<https://gpaoliveirablog.wordpress.com
<https://gpaoliveirablog.wordpress.com>>>/
-- -----------------------------------------------------------
-----------
* 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
<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,
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
------------------------
Andrew Premdas
blog.andrew.premdas.org <http://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
For more options, visit https://groups.google.com/d/optout.
Groups "Cukes" group.
For more options, visit https://groups.google.com/d/optout.