Management 3.0, Project Management

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

From Traditional QA Engineer to Agile test consultant

Quality Assurance in Traditional Software Development

Quality is an inherent element in agile development and it is commonly told that agile professionals are quality infected or test infected (Ambler, 2005). In traditional development processes, QA had never worked closely with software developers and was also not involved in the project in the early phases. They often played the so-called “gatekeepers” role telling project managers “Sorry, the requirements are frozen; we can add the feature in the next release.” (Lisa Crispin, 2009)

QA never controlled how the source code was written nor checked if the developers tested their code, neither collaborated with them in testing the code. QA carried out testing only post development and had the power to stop software releases from going forward if problems were identified. They were also involved in a lot of documentation work like creating test plans, bug tracking and reporting, change request, etc.

Traditional development cycles were long and the development teams focused on making sure all the specified requirements were delivered in the final product by the release date. In my experience, most of the time release dates were not met and were postponed to a future date. The development team was usually made of experts, and most of the time the team had no idea on what features were going to go live in the next release.

It was the QA’s job to read the requirements and create their test plans for the feature which was going to be released. Often the test plans were created from requirements parallel to the development of the product. QA engineers often had to wait for work as testing normally took place at the end of the project (Lisa Crispin, 2009).

Transition of Quality Assurance into Agile Software Development

The transition to short iterations of agile development produced an initial shock wave. This was also felt in the quality assurance department. Most of the QA engineers now also called as Agile Testers/Consultant whatever…. had questions in their mind and some of them were: how can I define requirements and then test and deliver the production department tested code in 2 weeks? How can I test parallel to development and that too within 2 weeks?

QA engineers also had to learn that the quality criteria would be defined by the customers or the Product Owners. They also had to be prepared for the challenge of testing a product based on acceptance criteria without any test plans. QA engineers were now part of the development team where the role of QA transformed from merely a tester or a bug finder in traditional software development into a consultant’s role who had to educate the development team in how they could improve the quality standards of the product with combined effort. QA engineers also had to learn how to code automatic tests as it became a necessity to maintain speed and make timely software releases. QA engineers took part in all Scrum meetings and perform manual acceptance testing tasks when coding was completed.

Initiation of QA activities in Traditional Development & Agile Development

Challenges in Agile Quality Assurance

Agile being iterative and incremental meant that the QA engineers had to test each incremented piece of code as soon as it was completed. A Scrum iteration is about 2 weeks long where the whole team collaborates to build and test a little piece of code or feature and makes sure it works. But what I found unusual from my interaction with agile consultants and developers was the level of “done” did not apply to the testing tasks. Normally developers should never get ahead of the testers/QA, because a story or feature is not “done” until it has been tested. Thus the collaboration between developers and testers was weak when it came to manual testing tasks; testers were solely responsible for manually testing tasks at the end of the user story. QA engineers were also held responsible for final acceptance tests on a shippable story on the staging environment before it was released live.

Although being agile has a lot of key benefits, adapting to this new process can be a challenging task. More involvement of customers and stakeholders in agile development has introduced a unique approach to meet requirements and specifications. Being agile also means that this methodology is flexible to change and more effective for development. Yet, agile methodologies have been under critic and are facing challenges to get an overall acceptance over traditional software development.In the next post i will try to point out some challenges QA engineers/ Agile Tester  are facing in agile development based on inputs from  semi- structured interviews, personal work experience and a survey.

Project Management

Agile Manifesto refreshed

Over the years agile software development encouraged people collaboration as compared to the traditional software development processes. It also responds to changes more effectively because the development process is incremental and iterative. In a single iteration of agile development approach all required phases of software development (planning, design, development and analysis) take place one after the other. After the completion of the iteration the software product is reviewed by the customer. The next followed iteration will start to add the required feature/functionality based on the customer feedback. The light weight agile methodology has also changed the way QA activities are performed.

Agile software development has changed the way software development used to work in the past. The agile approach prefers shorter iterations for software development processes unlike the traditional development approach. Agile processes also emphasise that the software development iterations should be shorter, incremental and people centric. The manifesto for agile development states:

Visual Representation of Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others to do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more (manifesto).