Agile Buddha

Demystifying Agile, Getting to its Core

Agile Testing

Specification by Example | Behavior Driven Development | ATDD – A Google Hangout Interview

by Leave a Comment

Recently I got interviewed by DiscussAgile on a topic known by several names, i.e. Specification by Example, Behavior Driven Development or Acceptance Test Driven Development.

Here’s the Google Hangout recording available on YouTube.

Following topics got discussed as part of interview:

  1. Why to do ATTD?
  2. How to do it?
  3. What skills are needed to do it?
  4. Who should do it?
  5. How it relates with Test Driven Development?
  6. Tools to BDD/ATDD.
  7. How to start?

Enjoy and provide your feedback.

Agile Testing is achieving quality in everything

by 1 Comment

We know “Testing As An Activity” is important, and why we should all test. The old axiom that “Testers Test and Programmers Code” is so outdated now and everyone needs to change. Testers are the testing experts in a team, and can help enable the whole team to own quality but they are certainly not the only one’s who should be testing. Like, developers need to contribute towards testing by unit testing their code and also pair testing to minimize defects and minimize test – defect-fix cycle.

Agil-Testing-Quadrants

Testing in agile, addresses the processes that produce software and also products of those processes. Hence I ask my teams to not just focus on validating software after development, but also check processes that produce software like, quality of stories, requirement/impact analysis, acceptance criteria(using behavior-driven-development to address “3 amigos problem), and more.

Take a look at our agile testing workshop which is a detailed 2 day course which focusses on test automation strategies, lean approach to defect prevention, various tools and techniques to automate, BDD(behavior-driven-development) and how to use various frameworks – Linear Scripting, Test Library Architecture, Data-Driven Testing, Keyword/Table-Driven and Hybrid automation frameworks.

When BDD (Behaviour Driven Development) may not work?

by 6 Comments

For quite some time there have been talks on using BDD in order to have:

  1. Better collaboration between Business Analysts (BAs), developers and testers.
  2. A common domain language for functional testing and for defining functional acceptance criteria, which everybody in the team understands.

Why BDD?

BDD offers following advantages:

  • Ability to write test cases (scenarios) and acceptance criteria before performing any development. This whole idea is termed as Acceptance Test Driven Development (ATDD).
  • Provides a common domain language, which everybody across the board (developer, tester, BA and business) understands. As at the end it’s plain English, it’s simplest to learn compared to other DSLs (domain specific languages).BDD example
    bdd-sample
  • Helps in eliminating waste by minimizing handshakes. If you take a look at the above-mentioned example, testers and BAs can write a test or acceptance scenario using a BDD template (highlighted in Yellow) with plane English

Developer/tester can then fill in the blanks, i.e. implement the test case using programming language or script.

Writing text doesn’t require any IDE like Visual Studio or Eclipse. The test/acceptance scenario can be written in a Notepad too and then pushed to Version Control System, which is then picked up by developers/testers to implement.

As BAs, developers and testers work only one single source of truth (BDD test), it minimizes the handshakes and reduces waste. Also it is well understood by everyone as test-scenario is in plain English.

[Read more…] about When BDD (Behaviour Driven Development) may not work?