[Cucumber] How much details should I add / should not to a user story
(too old to reply)
2018-05-16 15:16:51 UTC
Raw Message
Hi George,

Thanks for detailed clarifications.

Hi George,
Thanks for reply, please find answers embedded.
On Tuesday, May 8, 2018 at 4:30:58 PM UTC+2, George Dinwiddie
Hi, Vikram,
Hi All,
I'm using BDD techniques since last 2+ years and recently
a new
company who has got complex software similar to a trading
I'm pushing hard to use BDD in sprints.
With existing QA used to writing traditional test cases,
finding it
difficult to adopt to BDD style user stories.
- My Query is how much detail is good or bad
My rule (which I got from Dale Emery who credits it to Brian
Marick) is
"all the details that matter and none of the details that
don't matter.
Is there any article on this to refer ?
Not explicitly, but you might find
- I'm confused about too abstract user story vs too
detailed user
If you're willing to share some examples, I could offer my
opinions and
Scenario: As user I upload documents in user's application and it
reflected within few seconds in agent's application
- User needs to do 3 steps ( clicks ) to upload documents
- Agent needs to do 4 steps ( clicks, including refresh ) to find
recently upload document for particular user
The clicks are implementation details, and are likely to change. You
might find Dale's post http://cwd.dhemery.com/2010/03/layers/
<http://cwd.dhemery.com/2010/03/layers/> helpful
for thinking about the various layers of your tests. My book
<https://leanpub.com/EvolutionaryAnatomy/> gives some insight into
how I
separate test code into layers as I work.
Correct me if I'm wrong, but it seems to me that the behavior you're
trying to test is that when a user (customer?) uploads documents,
the agent (another type of user) sees that they are available.
Scenario: The agent can see documents that the customer uploads
When customer Bob uploads a new document "War_and_Peace"
Then the agent sees "War_and_Peace" in the list of Bob's
within 5 seconds
The clicks and timeouts get delegated down to the step definitions
lower. The step definition for uploading a document knows how to do
(perhaps through other code, such as a page object) and where to
find a
document to upload. The step definition knows how to view documents
user name, and how to search for a particular document in that list.
Now with Gherkin syntax should I add multiple Given And And...
just like
traditional test case steps ?
If you were telling a knowledgeable fellow tester what to test, you
probably wouldn't tell them exactly what to click. You'd say "login
"Bob" and upload a document, then login as an agent and look for
document in Bob's account."
The problem I see with this approach is if somebody new joins the
team, how s/he will understand implementation details ?
The best way to understand the implementation details is to read the
step definition. For example, the scenario step
When customer Bob uploads a new document "War_and_Peace"
might map to a step definition something like the following (pseudocode
void customer_uploads_new_document(customer_name, document_name) {
customer = find_or_create_customer(customer_name);
document = find_or_create_document(document_name);
upload_page = UploadPage.open(browser);
The further details of each of these things is contained in lower level
code. The UploadPage page object wraps all of the details needed to read
or interact with that page, things like element locators, which element
is the submit button, etc. Normally even a new person won't need to
delve into that unless something has changed and it's not working.
Suppose the button was named "Submit" and that was being used to locate
it on the page. If someone renames it "Upload" then the page object will
no longer be able to find it, so someone will have to edit the page
object code to tell it the current name.
It's a matter of seeing the intent of the scenario, first, and digging
into more detail as needed. The browser object, above, might be a
wrapper around a Selenium driver, that can keep the page object from
having to deal with the details of Selenium directly.
Does s/he needs to look into designs to map story to user actions ?
The step definition above is probably enough to understand the user
actions. You don't have to be able to write code to be able to read it
at that level.
Or s/he need to look into implementation of step definitions to
understand how exactly things work ?
There are different levels of "how things work." There's the level of
business intent. There's the level of clicks on a web page. There's the
level of Selenium calls. There's the level of packets on the network
interface. And others. You rarely need to think about the lowest level,
and if you talk in terms of the lowest, most-detailed level, then it's
harder for people to understand the point of what's being done.
Granted, it seems like a bit more work to write things clearly for
future audiences. I find that this work pays off quite quickly, in weeks
if not days, in my own ability to understand what I was doing when I
wrote it. But I try to keep in mind what someone, a new person or me,
needs in order to understand it a year from now.
- George
I'm trying to come up with solution which will help new comers into
the project.
In this case; Ghekin story will end up looking like test steps
- As per my 2 days of training from Cucumber, finding it
hard to
come up
with "Ubiquitous Language"
With whom are you trying to come up with an ubiquitous
Within QA team mainly ( also with developers ), as some members
are new
and need more details to understand exact working nature of
piece of software
If they're going to understand automated tests, they're going to
need to
learn to read some of the code underneath the gherkin. I'm surprised
that you don't mention anyone from the "business side" of things.
ubiquitous language is the language shared between the business and
development. Development includes both programmers and testers, to
my mind.
Does that help?
Thanks, these are valid points & I fully agree with it
- 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.