Agile testing methods – Behavior Driven Testing
Agile testing is a relatively newer approach to software testing. It follows the principles of agile software development as called out in the Agile Manifesto. About 10-12 years back, most of the projects were run in Waterfall fashion. However, With the basic advantage of quicker time to market, Agile methodology is gaining popularity now a days.
In Agile, software development and testing are continuous, and it is a collaborative effort between testers, developers, product owners and even customers and testing is not a separate phase like waterfall model.
The difference with Agile methodology is that the testing starts at the very start of the project, even before development has started and gives a continuous feedback to the development activity.
Also, as a thought process also, testing in agile methodology is different since the onus of quality lies with every one in the Agile team and not just QA i.e in a way everyone on the team is responsible for testing.
Agile Testing Methods :
1. Test Driven Development (TDD) :
- The term TDD was coined by Kent Beck in 2002
- In this methodology, Tests are written before functions.
- It relies on the repetition of a very short development cycle
- First the developer writes an initially failing automated test case that defines a desired improvement or new function
- Second, Developer produces the minimum amount of code to pass that test, and
- Finally refactors the new code to acceptable standards
The idea behind Test driven development is to make each change small enough to iterate rapidly. As you automate and implement each feature or a change you’ve basically added something valuable to your overall system, and you’re ready for a shippable product and product owner feedback.
(a). Behavior driven testing (BDD) :
- It was first described by Dan North in 2009.
- BDD is an extension of test-driven development (TDD).
- Product Owner, Programmer and Tester (3 amigos) are involved from the very start.
- Aids in application implementation from stakeholder point of view through use of given-when-then style of representing tests.
- BDD Shifts the vocabulary from being test-based to behavior-based.
- It May be interchangeably/loosely called
- Story telling
- Functional Testing
- Acceptance Test Driven Development (ATDD)
Since, BDD involves thinking in a common language, It helps teams to have the right conversations at the right time and thus maximizing the amount of valuable code produced. It also has potential to identify gaps in understanding and areas where we need more information before we actually know what is to be done.
2. Steps involved in BDD Test :
- First, take a small upcoming change to the system i.e a User Story or a scenario (Also known as Example in Context of Cucumber).
- Analyze new functionality to explore and agree on the details of what’s expected to be done by discussing between three amigos – BA, developer and tester.
- Document the scenarios in a way that can be automated.
- Lastly, implement the behavior described by each documented example, starting with an automated test to guide the development of the code.
A practical BDD project flow is described in figure below.
3. BDD vs ATDD vs TDD : Key differences
Behavior Driven Development (BDD) :
- More customer-oriented in nature and helps developers write tests keeping in mind the behavior desired by the stakeholders, and not tests to verify the code implementation.
- Customer focused and uses English like language, allowing easier collaboration with non-technical stakeholders.
- Gives clear understanding as to what the system should do from the perspective of the developer and the customer.
- In BDD tests fail because feature hasn’t been developed,
- Feature is based on what customer needs
Acceptance Test Driven Development (ATDD) :
- Starts by guiding the development team on what features are actually required to be built and then testing those features to verify their functionality. Hence, ATDD focuses at a high-level and TDD at a low-level.
- Do the right thing (Business Point of View).
- Gives the developer an understanding of what the system should do.
- Recent ATDD tools are inclining more towards using BDD-like language of Given, When, Then.
Test Driven Development (TDD)
- Tells the developer whether her/his code works fine.
- Do things right (Dev Point of View).
- In TDD tests fail because algorithm/function hasn’t been developed.
- Algorithm is based on what programmer knows
- Algorithm is based on what programmer knows
4. Cucumber and Gherkins :
- Important point to note is that Cucumber is not a Testing tool.
- Cucumber is a tool based on Behavior Driven Development (BDD) framework which is used to write User acceptance tests.
- Cucumber reads executable specifications written in English text and validates that the software does what the specifications are suggesting.
- Scenarios or Specifications for Cucumber are written in below format :
Scenario : <Detailed scenario description>
Given : This clause describes the pre conditions
When : This clause defines the trigger point or an operation.
Then : This clause defines the outcome of the event or the operation.
- Gherkin is a Business Readable, Domain Specific Language.
- It is simple to understand as it removes logic and syntax details from behavior tests.
- It uses a set of Keywords to make tests more understandable. Most commonly used keywords are : Feature, Given, When, The, Rule and many more.
- Gherkins has been translated to and can be used in multiple languages. This helps easy communication between Stakeholders and business users.
Advantages and Disadvantages :
- Tests written in Gherkins/Cucumber serve the dual purpose of tests and project documentation.
- Adopting BDD approach ensure a development process is built with the user experience in mind.
- This methodology requires lot of engagement among 3 amigos. This can serve as advantage or disadvantage depending the project situation.
Closing thoughts :
BDD approach can be a good choice when you need everyone on the team to be engaged without digging into technical aspects. Also, this approach is not ideal for all project types. Shorter projects may get delayed using this method. It can also make projects complicated and sometimes slow them down. It also requires a major mindset shift from the traditional way of working.