Behavior Driven Development with 3 Amigo’s task

In Scrum, a story is presented in planning with a story template that would look like:

As a [X]

I want [Y]

So that [Z]

This can be elaborated as the following, the person or the role “X” wants to have a feature “Y” so that he/she could be benefited by “Z”. But this could often lead to misunderstanding as depicted in figure below:

Representation of Communication Gap in a Story Grooming Meeting

Representation of Communication Gap in a Story Grooming Meeting

Everybody in the team could have a different understanding of the story being presented in the sprint planning and could de-scope some of the more esoteric requirements (North, 2006). This misunderstanding could be avoided with the help of sketches which could be presented in the sprint planning as depicted in figure below.

But a more feasible solution to this situation would be the use of a domain specific language (DSL). Every QA engineer knows that a story’s behavior is simply its acceptance criteria and if the system fulfills all acceptance criteria, then the system behaves correctly or vice versa. Therefore a QA engineer needs a template to capture a story’s acceptance criteria which could be done with Behavior Driven Development (BDD). (North, 2006)

Representation of Good Communication with Sketches

Representation of Good Communication with Sketches

BDD is usually done in DSL a very English-like language that helps the domain experts to understand the implementation rather than exposing the code level tests. It is defined in a GWT format, GIVEN WHEN & THEN (What is TDD, BDD & ATDD ?, 2012). The BDD template is loose and structured enough so that it could break the story into different scenarios based on its acceptance criteria. A scenario template would look like:

Given some initial context (the givens),

When an event occurs,

Then ensure some outcomes.

The QA engineer could develop these scenarios from acceptance criteria in collaboration with the Product Manager/Owner. The scenarios with “given”, “when an event”, “then an outcome” are fine-grained enough to be represented directly in the code. The QA engineer could collaborate with the developer to represent these scenarios in the code which would then be part of the acceptance test for the story. A simple representation of the scenarios in coded form would look like:

public class someinitialcontext implements Given {
public void setup(Someinitialcontextsomeinitialcontext) {
...
}
}


public class aneventoccurs implements When {
public void setup(Aneventanevent) {
...
}
}


public class ensuresomeoutcomes implements Then {
public void setup(Outcome outcome) {
...
}
}

Test Driven Development (TDD)

Test Driven Development (TDD)

BDD is test driven development (TDD) in many ways except that the word “test” is replaced by the word “Behavior” and is meant for a broader audience which include Product Owners and stakeholders. In both the methods of software development, the tests are written upfront and made executable, then implementation of a unit is done and finally the implementation of the unit is verified by making the test successful.

Implementation of 3 Amigo’s Task

The decision to implement the 3 Amigo’s task solely depends on the team if they want it. In my case the Scrum team wanted to try something new in the field of testing. The following process evolved which was loosely based on the  “Introducing the Three Amigos” by Ryan Thomas Hewitt. It was accepted as a sprint task and was defined and adopted by the Scrum team. The “3 Amigo’s” were the Product Managers/BA’s, the QA engineer, and a developer who collaborated together to define the scenarios from the acceptance criteria for a story.

Steps involved in 3 Amigo’s:

  • For every new story a task “3 Amigo’s” is defined in the sprint planning meeting.
  • “3 Amigo’s” task is considered to be the first task for every story in the sprint.
  • Immediately after planning the Product Owner, the QA engineer, and a developer create a meeting and collaborated together to define the scenarios.
  • The scenarios are represented as code by a pair of developers or a developer-QA engineer pair.
  • Development of the code is started parallel to or after the implementation of scenarios as executable acceptance test.

Advantages of Performing 3 Amigo’s Task:

  • Performing “3 Amigo’s” task within the sprint showed high level of collaboration between the three parties involved in the sprint: the Product Owner/Manager/BA, Developers and the QA engineer.
  • Performing this task also means that the acceptance tests were written and automated even before coding started.
  • The scenarios where written in Domain Specific Language (DSL), which means everybody in the team could understand the scenarios and no coding skills were required.
  • The QA engineer had more time performing exploratory test as story acceptance test was already automated.
  • The story was accepted automatically when all acceptance tests represented as scenarios were successful.
  • “3 Amigo’s” task could be a pre-planning task, where the QA engineer could collaborate with the Product Manager/BA and define scenarios for each acceptance criteria.
  • The scenarios could be presented directly in the sprint planning meeting to the whole team.

Future Experimental Work

  • “3 Amigo’s” task could be a pre-planning task, where the QA engineer could collaborate with the Product Manager and define scenarios for each acceptance criteria.
  • The scenarios could be presented directly in the sprint planning meeting to the whole team.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s