[Cucumber] How much details should I add / should not to a user story

[80Vikram]

Hi George,

Thanks for detailed clarifications.

Regards,
Vikram

Vikram,

Vikram,

Hi George,
Thanks for reply, please find answers embedded.
Regards,
Vikram
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

joined

a new

company who has got complex software similar to a trading

tool.

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
http://cwd.dhemery.com/2009/11/wmaat/
<http://cwd.dhemery.com/2009/11/wmaat/>
helpful.

- I'm confused about too abstract user story vs too

detailed user

story.
If you're willing to share some examples, I could offer my

opinions and

advice.
Scenario: As user I upload documents in user's application and it

gets

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/
<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,

then

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

documents

within 5 seconds
The clicks and timeouts get delegated down to the step definitions

or

lower. The step definition for uploading a document knows how to do
that
(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

by

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

as

"Bob" and upload a document, then login as an agent and look for

that

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);
browser.loginCustomer(customer);
upload_page = UploadPage.open(browser);
upload_page.setUploadFile(document);
upload_page.submit();
}
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

itself.

- 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

language?

Within QA team mainly ( also with developers ), as some members

are new

and need more details to understand exact working nature of

complex

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.

The

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
----------------------------------------------------------------------