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

[80Vikram]

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

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

- As per my 2 days of training from Cucumber, finding it hard to come up with "Ubiquitous Language"

Thanks in advance.

Regards,
Vikram

[George Dinwiddie]

Hi, Vikram,

On 5/8/18 9:25 AM, 80Vikram wrote:
> 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.

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

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

- George

>
> Thanks in advance.
>
> Regards,
> Vikram

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

[80Vikram]

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

Hi, Vikram,

On 5/8/18 9:25 AM, 80Vikram wrote:
> 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 ?
 

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

Now with Gherkin syntax should I add multiple Given And And... just like traditional test case steps ? 

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

 

[George Dinwiddie]

Vikram,

On 5/8/18 10:47 AM, 80Vikram wrote:
> 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 wrote:
>
> Hi, Vikram,
>
> On 5/8/18 9:25 AM, 80Vikram wrote:
> > 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/
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/ 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, then
the agent (another type of user) sees that they are available.

I might write such a scenario like this:

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

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

- George

[Tim Walker]

Howdy,

Tim my advice is to publish them as documentation with relish, or similar. I want them to tell a story. You will have both types, where it is helpful. It will always be subjective and Andrew Premdas will always have better ideas. Hard to see it in the features themselves. As real documentation it will be more obvious. Look at rspec mocks on relishapp.com. Focus on your domain model. The ubiquitous language is just behind. Go man, go. 

Thanks in advance.

Regards,
Vikram

--
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+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[80Vikram]

  The problem I see with this approach is if somebody new joins the team, how s/he will understand implementation details ?

  Does s/he needs to look into designs to map story to user actions ?

  Or s/he need to look into implementation of step definitions to understand how exactly things work ?
  
   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 Dinwiddie]

Vikram,

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
of no particular language):

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

[80Vikram]

Hi George,

Thanks for detailed clarifications.

Regards,
Vikram