Discussion:
[Cucumber] Should I use Cucumber/Gherkin if I don't plan to automate?
(too old to reply)
Kerry Todyruik
2018-01-08 23:38:54 UTC
Permalink
Raw Message
Hi,

I'm interested in Cucumber mainly because of the Gherkin syntax for writing
test cases. At this time, I don't plan on automating tests. I would just
like a consistent test case format, and test cases that can be shared.

Should I use Cucumber (Gherkin) for this purpose?

Thanks,
Kerry
--
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Thomas Sundberg
2018-01-10 15:28:26 UTC
Permalink
Raw Message
Hi!
Post by Kerry Todyruik
Hi,
I'm interested in Cucumber mainly because of the Gherkin syntax for writing
test cases. At this time, I don't plan on automating tests. I would just
like a consistent test case format, and test cases that can be shared.
Should I use Cucumber (Gherkin) for this purpose?
You can use Gherkin for this purpose. But you can also use something
else. the syntax of Gherkin will not be enforced unless you use it as
a basis for automation. You may or may not introduce all kinds of
interesting syntactial errors and similar.

I would look into Example Mapping[1] for a way to discover wanted
behaviour. I would probably not bother with Gherkin unless i used it
for automation.

/Thomas

[1] https://cucumber.io/blog/2015/12/08/example-mapping-introduction
Post by Kerry Todyruik
Thanks,
Kerry
--
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.
--
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
John Maxwell
2018-01-10 16:56:28 UTC
Permalink
Raw Message
Post by Kerry Todyruik
Hi,
I'm interested in Cucumber mainly because of the Gherkin syntax for writing
test cases. At this time, I don't plan on automating tests. I would just
like a consistent test case format, and test cases that can be shared.
Use a text editor, then.

Out of purest curiosity, how did you figure on "using" Cucumber without any automated tests?

-John

--
John Maxwell KB3VLL ***@jmaxhome.com

Speaking just for me, I don't think I have Linux blinders on my
eyes. I can see other platforms, but I *choose* to ignore them on the
theory that if I ignore them hard enough they will go away.

This theory is obviously crazy. However, it also appears to be working.

— Eric S. Raymond
--
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Andrew Premdas
2018-01-10 17:13:02 UTC
Permalink
Raw Message
I'm not sure the Gherkin syntax is very good for writing test cases that
are not automated. For me the major benefit of using Cucumber is be able to
write scenarios that only talk about WHY something is happening and that
define linguistically what something is. My scenarios never have anything
in about HOW something is done. I delegate this responsibility to the code
that automates the test and its interaction with my application.

This 'might' make is difficult to get anyone to actually use your test
cases for testing because the tests might not explain enough about how to
interact with the system. On the other hand you would get a great high
level specification of your application that would be very compact.

Some scenario examples to illustrate the issue/problem

Scenario: I sign in
Given I am registered
When I sign in
Then I should be signed in

Scenario: Go to checkout
Given I have products in my basket
When I go to checkout
Then I should see my products in the checkout

The second one really illustrates this. I'd imagine if you had 10 testers
they would find 10 different ways to put products in their basket. I'm not
sure if thats a good a bad thing!

All best

Andrew
Post by Kerry Todyruik
Hi,
I'm interested in Cucumber mainly because of the Gherkin syntax for
writing test cases. At this time, I don't plan on automating tests. I would
just like a consistent test case format, and test cases that can be shared.
Should I use Cucumber (Gherkin) for this purpose?
Thanks,
Kerry
--
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.
--
------------------------
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
George Dinwiddie
2018-01-10 17:46:51 UTC
Permalink
Raw Message
Ugh, Andrew.
Post by Andrew Premdas
I'm not sure the Gherkin syntax is very good for writing test cases that
are not automated. For me the major benefit of using Cucumber is be able
to write scenarios that only talk about WHY something is happening and
that define linguistically what something is. My scenarios never have
anything in about HOW something is done. I delegate this responsibility
to the code that automates the test and its interaction with my
application.
This 'might' make is difficult to get anyone to actually use your test
cases for testing because the tests might not explain enough about how
to interact with the system. On the other hand you would get a great
high level specification of your application that would be very compact.
Some scenario examples to illustrate the issue/problem
Scenario: I sign in
  Given I am registered
  When I sign in
  Then I should be signed in
Scenario: Go to checkout
  Given I have products in my basket
  When I go to checkout
  Then I should see my products in the checkout
The second one really illustrates this. I'd imagine if you had 10
testers they would find 10 different ways to put products in their
basket. I'm not sure if thats a good a bad thing!
I think those are terrible scenarios whether automated or not. They say
nothing about the intent of the product. They both fall into Richard
Lawrence's tautological category.

- George
--
----------------------------------------------------------------------
* 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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Andrew Premdas
2018-01-10 18:18:05 UTC
Permalink
Raw Message
Sigh ...

The idea that a happy path scenario like

Scenario: I sign in
Given I am registered
When I sign in
Then I should be signed in

is terrible because it is to simple is ridiculous. How would you want me to
write it?

This succinctly captures an important piece of behavior, names it and
drives the development of its functionality. It also provides a framework
to explore sadder paths e.g.

When I sign in with a bad password
When I sign in from a new ip address
...

It certainly says something very important about the intent of the product,
namely that it supports User accounts and signing in!!!

Don't underestimate what it does because it is so simple. Naming is one of
the hardest problems in computing!

Simple scenarios like these build on existing context and provide a
framework to explore sad paths and marginal paths. I suppose that the
scenarios seen out of context can be misunderstood but this tautology is
bad cos it doesn't mean anything argument is completely spurious. It misses
the fundamental truth that you can't have a tautology without a name and
having a name is a critical step on the journey to state intention and
describe behavior.

These tautological scenarios that you (and perhaps Richard) are so critical
off are actually a fundamental stepping stone to be able to converse
effectively about intent and explore what happens when you can and can't do
something.

Anyhow I look forward to your improved sign in scenario that explains with
greater clarity the intent that I want my application to allow people to
sign in. I expect all the extra stuff you'll put in your scenario to give
it meaning will be stuff that I already expect to be there in the features
name, location, and its pre-amble, but hey perhaps you can teach me
something new.

Andrew
Post by George Dinwiddie
Ugh, Andrew.
Post by Andrew Premdas
I'm not sure the Gherkin syntax is very good for writing test cases that
are not automated. For me the major benefit of using Cucumber is be able to
write scenarios that only talk about WHY something is happening and that
define linguistically what something is. My scenarios never have anything
in about HOW something is done. I delegate this responsibility to the code
that automates the test and its interaction with my application.
This 'might' make is difficult to get anyone to actually use your test
cases for testing because the tests might not explain enough about how to
interact with the system. On the other hand you would get a great high
level specification of your application that would be very compact.
Some scenario examples to illustrate the issue/problem
Scenario: I sign in
Given I am registered
When I sign in
Then I should be signed in
Scenario: Go to checkout
Given I have products in my basket
When I go to checkout
Then I should see my products in the checkout
The second one really illustrates this. I'd imagine if you had 10 testers
they would find 10 different ways to put products in their basket. I'm not
sure if thats a good a bad thing!
I think those are terrible scenarios whether automated or not. They say
nothing about the intent of the product. They both fall into Richard
Lawrence's tautological category.
- George
--
----------------------------------------------------------------------
* 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
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
George Dinwiddie
2018-01-10 18:40:34 UTC
Permalink
Raw Message
Andrew,
Post by Andrew Premdas
Sigh ...
The idea that a happy path scenario like
Scenario: I sign in
   Given I am registered
   When I sign in
   Then I should be signed in
is terrible because it is to simple is ridiculous. How would you want me
to write it?
I have yet to see a system built where the intent was to be signed in.
There's always something else that's desired, and the act of signing in
is just an implementation detail that's put in front of that desired action.

The real story behind authentication is *preventing* other people from
accessing data or actions for which they're not authorized.

I've discussed this before at
http://blog.gdinwiddie.com/2011/06/11/dont-you-have-to-login-first/
Post by Andrew Premdas
This succinctly captures an important piece of behavior, names it and
drives the development of its functionality. It also provides a
framework to explore sadder paths e.g.
When I sign in with a bad password
When I sign in from a new ip address
...
It certainly says something very important about the intent of the
product, namely that it supports User accounts and signing in!!!
Don't underestimate what it does because it is so simple. Naming is one
of the hardest problems in computing!
Simple scenarios like these build on existing context and provide a
framework to explore sad paths and marginal paths. I suppose that the
scenarios seen out of context can be misunderstood but this tautology is
bad cos it doesn't mean anything argument is completely spurious. It
misses the fundamental truth that you can't have a tautology without a
name and having a name is a critical step on the journey to state
intention and describe behavior.
These tautological scenarios that you (and perhaps Richard) are so
critical off are actually a fundamental stepping stone to be able to
converse effectively about intent and explore what happens when you can
and can't do something.
Anyhow I look forward to your improved sign in scenario that explains
with greater clarity the intent that I want my application to allow
people to sign in. I expect all the extra stuff you'll put in your
scenario to give it meaning will be stuff that I already expect to be
there in the features name, location, and its pre-amble, but hey perhaps
you can teach me something new.
Scenario: accessing email
When a registered user requests their email inbox
Then they are shown a list of received emails

Scenario: protecting email
When an unknown person requests Joe's email inbox
Then they are asked to authenticate

Scenario: suspicious access to email
When a registered user requests their email inbox from a new IP address
Then an access code is sent to their registered backup channel
And they are asked for the access code

-- George
--
----------------------------------------------------------------------
* 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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Andrew Premdas
2018-01-11 01:20:50 UTC
Permalink
Raw Message
Post by George Dinwiddie
Andrew,
Post by Andrew Premdas
Sigh ...
The idea that a happy path scenario like
Scenario: I sign in
Given I am registered
When I sign in
Then I should be signed in
is terrible because it is to simple is ridiculous. How would you want me
to write it?
I have yet to see a system built where the intent was to be signed in.
There's always something else that's desired, and the act of signing in is
just an implementation detail that's put in front of that desired action.
Its a starting point George and its a simple piece of behavior that gives
you the ability to build on. You may have many reasons why you want to sign
in and you explore these at length in other parts of your features. The
thing is those things tend to have the following characteristics

1. They are more complex
2. They are context specific

Often these things have to emerge from other places, like the features
pre-amble. But what I am doing here with this simple scenario is naming a
piece of behavior and automating its execution so that I can

1. Actually implement the sign in
2. Use it in all the other places that reveal business intent where sign in
is a pre-requisite.
Post by George Dinwiddie
The real story behind authentication is *preventing* other people from
accessing data or actions for which they're not authorized.
No its not always. There can be a number of reasons why we want 'sign in'
in our systems. Your assuming that your reason is everyone else's reason,
or perhaps you are simplifying. Anyhow Its not the job of a single scenario
to explain this real story. Its the job of pre-ambles and features with
many scenarios to do this.

I've discussed this before at http://blog.gdinwiddie.com/201
Post by George Dinwiddie
1/06/11/dont-you-have-to-login-first/
Post by Andrew Premdas
This succinctly captures an important piece of behavior, names it and
drives the development of its functionality. It also provides a framework
to explore sadder paths e.g.
When I sign in with a bad password
When I sign in from a new ip address
...
It certainly says something very important about the intent of the
product, namely that it supports User accounts and signing in!!!
Don't underestimate what it does because it is so simple. Naming is one
of the hardest problems in computing!
Simple scenarios like these build on existing context and provide a
framework to explore sad paths and marginal paths. I suppose that the
scenarios seen out of context can be misunderstood but this tautology is
bad cos it doesn't mean anything argument is completely spurious. It misses
the fundamental truth that you can't have a tautology without a name and
having a name is a critical step on the journey to state intention and
describe behavior.
These tautological scenarios that you (and perhaps Richard) are so
critical off are actually a fundamental stepping stone to be able to
converse effectively about intent and explore what happens when you can and
can't do something.
Anyhow I look forward to your improved sign in scenario that explains
with greater clarity the intent that I want my application to allow people
to sign in. I expect all the extra stuff you'll put in your scenario to
give it meaning will be stuff that I already expect to be there in the
features name, location, and its pre-amble, but hey perhaps you can teach
me something new.
Scenario: accessing email
When a registered user requests their email inbox
Then they are shown a list of received emails
This scenario has no Given to set up state. It combines the Given and When,
and because you are trying to use a scenario to do more than its capable of
it does a very poor job of stating intention. So its going to end up being
rather messy to implement. Its also slightly contradictory (accessing email
vs email inbox), and does nothing to explain why a user should see their
inbox first when they view they're email.
Post by George Dinwiddie
Scenario: protecting email
When an unknown person requests Joe's email inbox
Then they are asked to authenticate
Again no Given, why?
Post by George Dinwiddie
Scenario: suspicious access to email
When a registered user requests their email inbox from a new IP address
Then an access code is sent to their registered backup channel
And they are asked for the access code
Now this one kinda works but to actually implement it you will have to add
something like

Given there is a registered user with email

All of your scenarios above when implemented will need sign in to work.
That behavior has to be present and working before you can do any of these
things e.g. protect an inbox from access from strangers. Tautological
scenarios are so useful when automating and developing behavior because they

1. Name that behavior
2. Provide the simplest automation of that behavior
3. Provide a foundation to build and describe other behavior.

As an example of this even my simple sign in scenario needs to build on
behavior described by registration scenarios. So we will need somewhere

Scenario: Register
Given I am unregistered
When I register
Then I should be registered

Registration is another piece of behavior that we implement and then build
upon to create new behavior. As we implement Registration we need simple
scenarios to exercise it (the scenario above is a good starting point).
This pattern of creating building blocks of behavior, and then using those
blocks as tools to create new behavior is fundamental to having a set of
features that actually can become code and automate an application.

I use my sign in scenario as an example of this in many posts to illustrate
some of these points, because everyone can talk about sign in, its common
language. And because I don't have to deal with narrower areas of context
which require more explanation. When we cuke we should be aiming to create
common language that is specific to our particular applications as we learn
about and describe the behavior we need.

These scenarios are one small key part of the Cuke tool-set, and they are
all focused on the often ignored area of actually implementing cukes,
rather than the initial creation of Cukes. I don't expect 3 amigos to be
starting there conversations with we need registration and then sign in and
then two factor authentication and then I'd like my user to see their
inbox. I expect them to start with things like

I'd like to see my recent emails
I don't want anyone else to see my email
I'd like a way to notify users about suspicious

From there its a long journey before you can see your inbox and along the
way you will have to register and sign in etc. and having simple scenarios
in your set of features that confirm you can indeed register and sign does
prove to be very useful.

Finally at some point you will be able to write something like

Given I have new mail
When I view my inbox
Then I should see my new mail

and even though you have to be registered, signed in you'll be able to talk
about 'new mail' without having to worry about all that stuff so that you
can then implement

When I view my new mail
Then I should see lots of annoying adverts

and your bossed will finally be happy!!!

All best

Andrew

ps. when writing this I realized that my tautological scenarios actually
are indicators of functional maturity. They show that I can talk about a
particular topic so simply that it requires no further explanation, and now
is so well understood that we really don't need greater explanation.
Wouldn't it be great if all the other parts of our applications could be
understood so clearly
Post by George Dinwiddie
-- George
--
----------------------------------------------------------------------
* 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
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
George Dinwiddie
2018-01-10 18:15:24 UTC
Permalink
Raw Message
Kerry,
Post by Kerry Todyruik
Hi,
I'm interested in Cucumber mainly because of the Gherkin syntax for
writing test cases. At this time, I don't plan on automating tests. I
would just like a consistent test case format, and test cases that can
be shared.
Should I use Cucumber (Gherkin) for this purpose?
I wouldn't say *should*, but you certainly *could* use Gherkin to
express the intent of system functionality. I've had clients who didn't
automate all of their scenarios. They tagged some as @Manual to exclude
them from test runs, and to allow printing them all out using the
"pretty" formatter plugin. (Their step definitions had empty bodies.)

The key is to capture the intent in the gherkin. That's something I talk
about frequently. I suppose I should write something up on that.

- George
--
----------------------------------------------------------------------
* 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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Marty Bradley
2018-01-10 18:23:28 UTC
Permalink
Raw Message
Gherkin is a great language to use to collaborate on features and
acceptance test criteria. I use it all the time when coaching agile
transformations. I also urge you to automate :) There I had to say it

Post by Kerry Todyruik
Hi,
I'm interested in Cucumber mainly because of the Gherkin syntax for
writing test cases. At this time, I don't plan on automating tests. I would
just like a consistent test case format, and test cases that can be shared.
Should I use Cucumber (Gherkin) for this purpose?
Thanks,
Kerry
--
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.
--
Marty Bradley
Enterprise Agile Coach
(703) 869-2217
http://www.linkedin.com/in/martybradley
Click to scan contact information
<http://api.qrserver.com/v1/create-qr-code/?data=BEGIN%3AVCARD%0AFN%3AMarty%20Bradley%0ATEL%3A%28703%29%20869-2217%0AEMAIL%3Amarty.agilecoach%40gmail.com%0AURL%3Ahttp%3A%2F%2Fwww.linkedin.com%2Fin%2Fmartybradley%0AN%3ABradley%3BMarty%0AORG%3AEnterprise%20Agile%20Coach%0AVERSION%3A3.0%0AEND%3AVCARD%0A&size=500x500>
--
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
George Dinwiddie
2018-01-10 19:20:50 UTC
Permalink
Raw Message
Kerry,
Post by Kerry Todyruik
Hi,
I'm interested in Cucumber mainly because of the Gherkin syntax for
writing test cases. At this time, I don't plan on automating tests. I
would just like a consistent test case format, and test cases that can
be shared.
Should I use Cucumber (Gherkin) for this purpose?
I wouldn't say *should*, but you certainly *could* use Gherkin to
express the intent of system functionality. I've had clients who didn't
automate all of their scenarios. They tagged some as @Manual to exclude
them from test runs, and to allow printing them all out using the
"pretty" formatter plugin. (Their step definitions had empty bodies.)

The key is to capture the intent in the gherkin. That's something I talk
about frequently. I suppose I should write something up on that.

- George
--
----------------------------------------------------------------------
* 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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Kerry Todyruik
2018-01-10 22:43:53 UTC
Permalink
Raw Message
Hi,

Thanks for everyone's input. I worded that a bit strongly when I
communicated my intent to not automate. I put it that way more to elicit
clear feedback as to whether Gherkin is useful on it's own. At this time my
issue at the top of my list is that manual test scenarios in our
organization are inconsistent. I was thinking that Gherkin syntax could be
a means to encourage consistency when writing manual test cases. I was
thinking to encourage our QA testers to try writing tests using
Given-When-Then style and if that takes, have a look at automating later. I
was curious if others have used it in this way.

I've googled around and haven't seen any alternatives to Gherkin that could
be used in this way. Did I miss anything?

Thanks!
Kerry
--
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Andrew Premdas
2018-01-11 01:53:20 UTC
Permalink
Raw Message
First of all apologies for the thread hijacking in my discussion with
George.

I alluded to 2 approaches to describing manual tests

1. Specifying precisely what the tester should do
2. Using a much higher level abstract description of what the tester should
do

Both have problems

1. Takes ages to write, error prone, hard to maintain as application
changes, testers tend to blindly follow the instructions and can easily
miss bugs, especially visual bugs

2. Inconsistent (different testers will do different things), failures can
be hard to reproduce, difficult to know if test has been done properly

GWT is a restrictive language designed to support test automation and works
best when you use higher levels abstractions. So if you prefer the first
style of manual testing (which I suspect most people do) you will end up
with very long and messy scenarios that won't automate well. These will be
expensive to change as your application develops.

Finally on offbeat suggestion, consider other media for documenting your
tests e.g. video with commentary

Hope thats useful (please bear in mind I don't know much about manual
testing)

All best

Andrew
Post by Kerry Todyruik
Hi,
Thanks for everyone's input. I worded that a bit strongly when I
communicated my intent to not automate. I put it that way more to elicit
clear feedback as to whether Gherkin is useful on it's own. At this time my
issue at the top of my list is that manual test scenarios in our
organization are inconsistent. I was thinking that Gherkin syntax could be
a means to encourage consistency when writing manual test cases. I was
thinking to encourage our QA testers to try writing tests using
Given-When-Then style and if that takes, have a look at automating later. I
was curious if others have used it in this way.
I've googled around and haven't seen any alternatives to Gherkin that
could be used in this way. Did I miss anything?
Thanks!
Kerry
--
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.
--
------------------------
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Marit van Dijk
2018-01-18 07:49:20 UTC
Permalink
Raw Message
Kerry,


If the tests are currently inconsistent with each other, I'd be curious as
to the reason why? Maybe different testers in the team have a different
idea of what constitutes a good test or what level of detail should be in
the test description. Also regarding the two levels of testing mentioned by
apremdas:
Some testers may need/prefer detailed description of what to do (especially
if they're new in the team / unfamiliar with the product).
Others may prefer more high level descriptions and even use different ways
to test it *by design* (you'd get better coverage that way).

Ofcourse I don't know what type of inconsistencies you have...
However, it might be worth to discuss with the team what the expectations
are and how the tests should be written to be more consistent (level of
detail, wording, whatever is inconsistent now). You would need to have a
discussion with the team to find out and clarify though.
Gherkin is intended to capture the outcome of discussions regarding
functionality; there's no substitute for communication.
Even with the GWT structure there are many ways one could write Scenarios.
Just using the GWT structure is no guarantee it will be used consistently
by different people...

Finally, I do agree you will get the most benefit if you also automate. In
addition, this *may* help you to be more consistent in writing scenarios:
As you have to implement each step, it will bring great benefit to describe
steps consistently so you will get the most use of out reusing steps in
different scenarios.

Good luck!
Post by Kerry Todyruik
Hi,
Thanks for everyone's input. I worded that a bit strongly when I
communicated my intent to not automate. I put it that way more to elicit
clear feedback as to whether Gherkin is useful on it's own. At this time my
issue at the top of my list is that manual test scenarios in our
organization are inconsistent. I was thinking that Gherkin syntax could be
a means to encourage consistency when writing manual test cases. I was
thinking to encourage our QA testers to try writing tests using
Given-When-Then style and if that takes, have a look at automating later. I
was curious if others have used it in this way.
I've googled around and haven't seen any alternatives to Gherkin that
could be used in this way. Did I miss anything?
Thanks!
Kerry
--
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
80Vikram
2018-01-11 15:53:34 UTC
Permalink
Raw Message
Hi Kerry,

You should definitely use "*Gherkin*" syntax to write *user stories* and to
do that you can follow BDD approach involving 3 amigos to explore, clarify
& write user stories.

Cucumber is the tool which comes into play in case you want to link these
stories with some programming language.

I recommend you to check out https://hiptest.net/ for your need.

Regards,
Vikram
Post by Kerry Todyruik
Hi,
I'm interested in Cucumber mainly because of the Gherkin syntax for
writing test cases. At this time, I don't plan on automating tests. I would
just like a consistent test case format, and test cases that can be shared.
Should I use Cucumber (Gherkin) for this purpose?
Thanks,
Kerry
--
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...