BDD Acceptance Criteria Writing !

Acceptance testing doesn't actually mandate the conversations, and usually works from the assumption that the tests you're writing are the right tests. In BDD we assume that we don't know what we're doing (and probably don't know that we don't know). This is why we use things like "Given, When, Then" - so that we can have conversations around the scenarios and / or unit-level examples. (Those are the two levels most people are familiar with - the equivalent of acceptance tests and unit tests - but it goes up the scale).

We don't call them "acceptance tests" because you can't ask a business person "Please help me with my acceptance test". They'll look at you with a really weird, squinty gaze and then dismiss you as that geek girl. 93% of you don't want that.

Acceptance testing doesn't actually mandate the conversations, and usually works from the assumption that the tests you're writing are the right tests. In BDD we assume that we don't know what we're doing (and probably don't know that we don't know). This is why we use things like "Given, When, Then" - so that we can have conversations around the scenarios and / or unit-level examples. (Those are the two levels most people are familiar with - the equivalent of acceptance tests and unit tests - but it goes up the scale).

We don't call them "acceptance tests" because you can't ask a business person "Please help me with my acceptance test". They'll look at you with a really weird, squinty gaze and then dismiss you.

When you write a story, it always has at least one acceptance criteria attached to it (and if the story itself is written as though it were a happy path, that acceptance criteria can be the story itself). But stories usually have more acceptance criteria than just the happy path. Writing acceptance criteria, along with tying them into end to end scenarios makes your story or narrative ready for development. Never go into development without the story or narrative having:

• priority
• story or narrative (depending on complexity)
• acceptance criteria
• knowing what the end to end test scenario is /are
• sign off from the customer for all of the above
• an estimate from iteration based on all of the above

Acceptance Criteria focuses on the vertical testing of that story in every way possible, and should be written in such a way that anyone testing it or developing it understands.

Implementation

When writing Acceptance Criteria, identify the primary purpose and scope. Clearly defined scope keeps the specification content focused. Define what scenarios are in scope and scenarios not in scope. A use case will define a single path through the functionality. There are generally at least a few use cases per story narrative. Effective acceptance criteria is detailed / specific and unambiguous. It should not use subjective language (Fast, Good, Better), or generalisations (Always, Never etc).

SMART Method

Keep SMART in mind when defining acceptance criteria: Specific, Measurable, Achievable, Relevant, Time-boxed.

Methods to writing acceptance criteria

Acceptance Criteria can be fleshed out in 2 ways; Scenario style or Behavior Driven Development (BDD) style.

Scenario style approach to acceptance criteria

This approach is useful when its easy to capture end to end test scenarios (the way the user will actually use the system). It's based on scenarios versus discrete acceptance criteria.
In general, scenario style focus on 'happy' and 'alternate' paths through the functionality and are always written the way the user would complete the action they are trying to take.

ATM example of withdrawing cash:
What is the user story?
As an account holder I would like to withdraw cash from an ATM so that I have money to spend.

Happy Path

For a favourable outcome what business conditions need to be met?
Account Holder enters valid pin
Account Holder has a balance matching or exceeding requested amount
ATM has cash matching or exceeding requested amount
So what should happen when the Account Holder tries to withdraw cash?
ATM dispenses requested cash immediately
Account Holder's balance is reduced
ATM cash balance is reduced
We've just described the happy path for the ATM withdrawal story. The business conditions were identified, and the acceptance criteria we can use to validate that the solution meets the customer's needs was listed.

Alternate path

The path with some deviations that allows users to reach the desired outcome
ATM example continued:
What if any of the business conditions identified in the previous exapmles were not true?
What if the Account Holder enters an amount greater than his balance?
Indicate that there are insufficient funds in his account
Can we stop here? Can we provide some functionality that will allow the user to still reach his goal?
Display a message and Provide option to specify a lesser amount
We can still satisfy the goal even though the path is not direct. This is what some people call an "Alternate Path". This is still acceptable as it allows user to reach his goal.

Bad Path

That path that does not lead to the desired outcome
ATM example continued:
What else can happen? Can something go totally wrong?

For example, maybe you cannot connect to the Bank

Account Holder's card has expired

Unexpected error in the system. Buffer overflow, Null Pointer.

We try our best to prevent these from occurring by writing more test, adding more functionality that caters to these situations (adding resilience). And provide a graceful recovery from unexpected outcomes - error messages and return to start page.

BDD style acceptance criteria

The Behavior Driven Development approach allows us to set the context for each test condition. This approach helps tease out all possible conditions that can affect the story.
Format:
Given 

When

Then

ATM example continued:

The happy path acceptance criteria for cash withdrawal is:

Given that my account has a positive balance, and the ATM has sufficient funds

When I enter a valid pin and ask for the an amount that the ATM can deliver and less than my balance,

Then the ATM will dispense that exact amount and debit my account by the same figure.

The nature of Acceptance Criteria 

• Elaborate stories
• Corroborate stories
• Are described by the business - normally during the development phase
• Are a set of conditions that the story must meet for it to be accepted as complete
• Acceptance criteria do not replace the conversation they are one of the results of the conversation
• Are abstractions of what business value will be observed
• Are generally not tests - tests are concrete e
• Writing Acceptance Criteria
• Should be derived with the customer
• Should be derived with someone technical in the room. Is what we are discussing technically possible?
• Ask the customer what they will observe when the story is successfully complete
• Ask more than one person
• May be many criteria
• All must be met before the story can be accepted

Considerations:

• Environment/Conditions/Context
• Actor involved
• Verb/Actions
• Observable result

Watch out for

• Ambiguous language
• Subjective/Judgemental language (Better, Good, Allowable)
• Generalisations (All the time, Never, Everyone, Always)
• Observed behaviour that is not directly related to the story currently under consideration.

BDD User Stories and Scenarios !

Behavior Driven Development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes. Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria. This article introduces the BDD approach to defining and identifying stories and their acceptance criteria and art of writing scenarios.

The structure of a story

BDD provides a structure for a story. This is not mandatory – you can use a different story format and still be doing BDD – but I am presenting it here because it has been proven to work on many projects of all shapes and sizes. At the very least, your story should contain all of the elements described in the template. The story template looks like this:

Title (one line describing the story)

Narrative:

As a [role]

I want [feature]

So that [benefit]

Acceptance Criteria: (presented as Scenarios)

Scenario 1: Title

Given [context]

And [some more context]...

When  [event]

Then  [outcome]

And [another outcome]...

Scenario 2: ...

Imperative vs Declarative Scenarios in User Stories

In my opinion, both styles have benefits and should be used appropriately based on the situation. The majority of examples on rspec's story runner currently on the web, are of the imperative type. Since the declarative type has many advantages I thought it would be worth while to present some examples and contrast the differences between the two styles.

Let’s look at the example: in Imperative Style

Story: User Registration

Feature: 

  As a User 

  I want to create a new user registeration to the site

  So that I can share my profile with the community

  Scenario: successful submission

  Given I'm on the user creation page

  When I fill in Name with ‘Manish’

  And select Gender as ‘Male’

  And fill in Username with 'agile_manish'

  And fill in Password with 'mypassword123'

  And Select in Occupation with 'Private Job'

  And check Terms and Conditions

  And click the Create button

  Then I should see the notice 'Thank you for your submission!'

  And the page should include the user name, gender, username, occupation

The imperative style uses highly reusable granular steps which outlines much of the user interface. This binds the scenario to that interface and requires more design decisions made up front. The step matchers for these granular steps are very easy to write. Once these steps are in place you can write the majority of your scenarios in this fashion without having to write custom step matchers. Due to the granularity of the scenarios however they become very brittle as they are subject to requirement changes from the customer. If a new field is added, for example, you must update the scenario to reflect this even though the underlying goal of the scenario has not changed.

Lets rewrite the above example in a more declarative fashion. The story narrative and scenario title will remain the same in Declarative Style

  Story: User Registeration

  Feature: 

  As a User

  I want to create a new user registeration to the site

  So that I can share my profile with the community

  Scenario: successful submission

  Given I'm on the user creation page

  When I add a new user

  Then I should see the page for my newly created profile

  And the notice 'Thank you for your submission!'

This style is more aligned with User Stories in the agile sense having more of the "token for conversation" feel to it. The first thing that you should observe about this style is how much smaller it is than the imperative one. This is a good thing. The imperative style tends to produce noisy scenarios that drown out the signal. With the declarative style the goal of the scenario remains clear. When a new field is added to the form the scenario does not have to be modified. Yes, you will have to modify the underlying step matcher but the scenario does not have to suffer dilution due to the change. The trade off is, of course, that you will now be writing step matchers for all of your scenarios.

Choosing Which Style To Use

I have made a strong case for the declarative style of writing scenarios. It would seem that one should never write a scenario imperatively based solely on the merits of maintenance and communicating story intent. While I think the declarative style has much strength it is not the best choice for all situations. The imperative style should not be discounted entirely because when used judiciously in the right scenario it can highlight certain aspects of the functionality and improve communication. It is also important to realize that the two types are not mutually exclusive. The styles can be mixed throughout an app, a story, and even an individual scenario to provide the appropriate level of granularity as the situation demands.

Getting Started With HTMLUnitDriver: A Silent Simulator !

HTMLUnitDriver

This is currently the fastest and most lightweight implementation of WebDriver. As the name suggests, this is based on HtmlUnit. HtmlUnitDriver is a class of Interface WebDriver using namespace as OpenQA.Selenium.Remote; 

HtmlUnitDriver, a pure Java driver based on HtmlUnit browser simulator (all Java-capable OS).When running, you won’t see any window opening because it doesn’t render any page like Firefox would. You can’t use it to get size or position of pages' elements

It is very fast but does not provides JavaScript yet: this feature is still a WIP. If you want to use it anyway, use  desiredCapabilities.IsJavaScriptEnabled = true;

FirefoxDriver: supports Firefox (2.x and 3.x, all OS)

InternetExplorerDriver: supports InternetExplorer (tested on IE6, 7 and 8, should work on IE5.5 and on Windows XP and Vista)

ChromeDriver: drives Google’s browser (>= 4.0, all OS)

To use HtmlUnit you need to use the RemoteWebDriver and pass in the desired capabilities for it. Beloe code will help you to run application using HTMLUnitDriver using .Net. Note that you’ll need to run the remote WebDriver server to useHtmlUnit from C#

1. There is no Class HtmlUnit  in C# (dlls for Selenium)

2.  HtmlUnit  is really fast

We can walk through in this method:

1. Install  Selenium Server and start it using java -jar selenium server path

2.  To get an instance of the HtmlUnit Driver.

IWebDriver drive = new RemoteWebDriver(DesiredCapabilities.HtmlUnit());

---------------------------------------------------

using System;
using System.Configuration;
using OpenQA.Selenium.Remote;

               public static IWebDriver WebDriver;

               var remoteServer = new Uri("http://localhost:4444/wd/hub/");

               DesiredCapabilities desiredCapabilities = DesiredCapabilities.HtmlUnit();

               WebDriver = new RemoteWebDriver(remoteServer, desiredCapabilities);

               desiredCapabilities.IsJavaScriptEnabled = true;

               WebDriver.Manage().Timeouts().ImplicitlyWait(new TimeSpan(0, 0, 30));

               //go to url 

               WebDriver.Navigate().GoToUrl("http://google.co.in");

BDD | Art of Writing Good Feature Files !

Art of Writing Good Feature Files using Gherkin Keyword(s)

Clearly writing good feature files is important. However writing good feature files, as any good documentation, takes time, effort and collaboration.

Here’s  are the tips for what makes a good feature file:

·         About the business domain – not software design

·         In domain language

·         Specification – not a script

·         Easy to understand

·         Focused on a single thing

·         Precise and testable

·         Self-explanatory

·         Consistent

·         Easy to access

Gherkin Keyword and it’s Usage

•   Tags

Tags are a great way to organize your features and scenarios. Consider this 

@Pegasus Release 3.11

Feature: User Creation

         In order to Create user

              As a Workspace admin

               I want to create a ws user

@sprint1

Scenario Outline: Login as Course Space Admin

• Feature

Every .feature file conventionally consists of a single feature. A line starting with the keyword Feature followed by free indented text starts a feature. A feature usually contains a list of scenarios. You can write whatever you want up until the first scenario, which starts with the word Scenario.

Feature: WS Admin

       In order to Creation of Course and Enrolling the Students

       As a WS Admin

       I want to be create courses and users

·         Background

Background allows you to add some context to the scenarios in a single feature. A Background is much like a scenario containing a number of steps. The difference is when it is run. The background is run before each of your scenarios but after any of your Before Hooks.

Background:

 Given I have browsed url for "WSAdmin"

 And I logged in as Ws Admin

•  Scenario

Every scenario consists of a list of steps, which must start with one of the keywords Given, When, Then, But or And. SpecFlow treats them all the same, but you shouldn’t.

Scenario: Create the new Course using create course link in right pane

       Given I have logged into the workspace as WSAdmin

       Then  It should be on "Course Enrollment" page

       When  I clicked on the "Create New Courses" link in "right" frame

•   Scenario Outline

Copying and pasting scenarios to use different values quickly becomes tedious and repetitive. Scenario outlines allow us to more concisely express these examples through the use of a template with placeholders. The Scenario outline steps provide a template which is never directly run. A Scenario Outline is run once for each row beneath it (not counting the first row). This scenario is a data driven scenario, it runs the scenario for every iteration in your examples table.

Scenario Outline: Login

       When I enter in the username field

       And I enter in the password field

       And I press Login

       Then the response Page is Course Enrollment

       Examples:

              | username     |password |

|bdd_ws_admin1 |password2|

|bdd_ws_admin2 |password2|

|bdd_ws_admin3 |password2|

You can also use placeholders in Multiline Step Arguments, Multiline step arguments come in two flavours – tables or strings.

Tables:

Tables as arguments to steps are handy for specifying a larger data set - usually as input to a Given or as expected output from a Then.

When I click the Create New User link

Then Enter the user details in Create New User popup  

        | Field          | Value                |

        | txtPassword    | password1            |

        | txtFirstName   | QA                   |

        | txtLastName    | BDD                  |

        | txtEmail       | bdd@gmail.com        |

When I click the Save button

String:

Multiline Strings (also known as PyStrings) are handy for specifying a larger piece of text. This is done using the so-called PyString syntax. The text should be offset by delimiters consisting of three double-quote marks (""") on lines by themselves:

Scenario: Fill in The Blank Question Creation

  Given a question named "Random" with:

    """

    Some Title, Eh?

    ===============

    Here is the first paragraph of my blog post.

    Lorem ipsum dolor sit amet, consectetur adipiscing

    elit.

    """

•   Examples

The placeholders indicate that when the Examples row is run they should be substituted with real values from the Examples table. If a placeholder name is the same as a column title in the Examples table then this is the value that will replace it.

Examples:

              | username     |password |

|bdd_ws_admin1 |password2|

|bdd_ws_admin2 |password2|

|bdd_ws_admin3 |password2|

•   Given

The purpose of Given steps is to put the system in a known state before the user (or external system) starts interacting with the system (in the When steps). Avoid talking about user interaction in givens. If you have worked with use cases, givens are your preconditions.

Scenario: Copy courses       

        Given MasterLibrary Course is present after do search

•  When 

The purpose of When steps is to describe the key action the user performs (or, the state transition).

Scenario:Create the new Course using create course link in right pane

       Given I have logged into the workspace as WSAdmin

       Then  It should be on "Course Enrollment" page

       When  I clicked on the "Create New Courses" link in "right" frame   

       Then  I should see the "Create New Course" popup

•  Then

The purpose of Then steps is to observe outcomes. The observations should be related to the business value/benefit in your feature description. The observations should inspect the output of the system (a report, user interface, message, command output) and not something deeply buried inside it (that has no business value and is instead part of the implementation).

When I click the Save button

Then It should display successful message New user created successfully

•   And, But

You can use And or But steps, allowing your Scenario to read more fluently. SpecFlow interprets steps beginning with And or But exactly the same as all other steps. It doesn’t differ between them - you should!

Scenario:Create the new Course using create course link in right pane

       Given I have logged into the workspace as WSAdmin

       Then  It should be on "Course Enrollment" page

       When  I clicked on the "Create New Courses" link in "right" frame   

       Then  I should see the "Create New Course" popup

       When  I enter the course name with prefix "ML"

       And   I clicked on the Save button of 'Create New Course' popup

       Then  It should display successful message "New course created successfully."

       But   I don’t see the "Create New Courses" link in "right" frame

•   Comments

You can write comments for each Feature(s), Scenarios or for Steps using keyword #

# This Scenario is to Verify Course Creation

Scenario:Create the new Course using create course link in right pane

       Given I have logged into the workspace as WSAdmin

       Then  It should be on "Course Enrollment" page

 The idea is that the indented bullets would signify a shorthand for repeating the introductory part of the step text (in this case "Then I should see").

When I enter in the username field

And I enter in the password field

And I press Login

Then I should see:

                * that there is Logout link

                * that there is MyProfile link

                * that there is Customer Support link

       Examples:

       |username     |password|

       |sel_ws_admin|password2|