Foreword:
User stories convey the most intricate features designed by software companies in lucid language for benefit of end-users. Usually, the stakeholders, clients, development team, or users write the user stories. Behavioural Driven Development (BDD) is a software approach that advances from Test Driven Development (TDD). It focuses on bridging the communication between the technical team and the end-users.
How to choose Behavioural Driven Development (BDD)?
Non-technical language is suitable for creating user stories. The reader should understand the purpose of the existence of that software. This is possible with interpretations to help other users. Focus on the user; make it a stepwise process to outline the tasks, set expectations from the system. Allocate responsibilities, and define scope that encourages the team to serve better.
Multiple discussions with users, lending ear to their problems and needs, and creating stories that are sources for requirements for the development team. Staging of users stories like to-do lists, making complete and review the pending status. Have discussion for implementable, and the requirements that need revisiting in order to make them useable. After the release of features, the confirmation from users for benefits or the mismatched expectations is equally important.
Benefits of BDD:
- A modern and reliable process of requirement analysis
- Introduce best software development practices
- Clarity of user requirements and scenarios that need to be programmed
- Contributes to the overall value of the software
- Visual presentation of the projects allows in planning workflow and customization of software
- Frequent releases due to changing requirements to gain from user stories
- Developers get continuous feedback that enables them to identify the areas that need improvement
- Clears pictures of what if for the end-users
- Technical stories appropriately convey the purpose and profitability
- Clear concepts of business domain help in coding and meeting system expectations
Drawbacks of BDD:
- The need for a new feature is indistinct and lacks user involvement
- Undefined structure of sharing user stories
- Fails if the goal is not defined
- Maintaining the user stories if difficult if the projects are huge
- User stories may miss out important features and may not highlight how the technology is built
- Risks pertaining to the technology are not enclosed
- Splitting of stories need a proper connection for the users to get hang of it
- Role-based feature development in case of severe complexities
Precautions for BDD:
- Keep the descriptions really short make it worthy of reading
- Use simple language and avoid using jargons
- If needed include a glossary for reference and better understanding
- Introduce product features that clients actually need
- Frequent communication with end-user stops wasted efforts and saves time
- Technical functions should be written by the developers and testers
- Business specific stories that are explanatory of benefits for different roles
- Proper documentation and acceptance tests confirm the stories
- Story map to arrange and re-arrange the user stories
- Get clarity on the backlog in product development
Are templates advisable for BDD acceptance criteria set for user stories?
Uniformity across the user stories creates a precise flow of communication for reference by the end-users. Easy to understand format enables filing the details in a series that effortlessly allows the reader to draw maximum benefit from the user stories. Simplicity and consistency being the main criteria the user story it is independent of conditions that influence the outcome. Though the formats make user stories presentable do not hook them to strict descriptive narrations that lose the value. A user story should ideally be short for the team to complete the work in a couple of days and test the BDD.
Create a template that suits your overall requirement, ideally it should cover what, why, when, where, when, and how.
BDD Story Sample Template:
Being a
My role is
What I am looking for are features that:
My scenario based experience encourages me to use this software as:
Where the issue is identified:
How is that helping me to take action:
When the outcome is
Why do I prefer this tool/software because:
Validation messages if the user has not entered parts of information or is trying to submit it blank brings control over user stories.
Using Template for creating a user story in BDD:
Being a customer: I want to see different available software for CRM
My role is: to compare the best available software in the market
What I am looking for are features: that are latest but let me maintain my traditional values of pharmaceutical manufacturing business
My scenario based experience encourages me to use this software as: it keeps contacts and tracking in one place
Where the issue is identified: we are capable of taking actions based on real-time data
How is that helping me to take action: is that we are in a position to respond quickly and our accuracy has improved
When the outcome is as expected: doing business becomes easier
Why do I prefer this tool/software because: it enhances the overall productivity of my team
How to apply BDD acceptance criteria in User Stories?
Define behaviour of software using simple language for a valid scenario using specific examples to validate the user experience. Goals give a new perspective to people involved in creating user stories. Split the details in short notes that are easy to store, understand, and apply.
Conversations and programming without context and perfection delivered in software have no significance. Continually strive to simplify the use, eradicate complications, and minimize the efforts of the users. Design software to congregate the queries and responses to suit the business needs.
It should meet the preconditions, act as defined in given scenarios, trigger, and notify the issues. Encourage timely actions, and function towards expected outcome. Consideration of validations for each field and in each scenario is necessary.
BDD acceptance criteria based user story for retail order:
It consists of the policy related and action base documentation, acceptance criteria for a new order, cancelled order, delivered order, replacement order, and returns. Insert validations for each field, what information will be stored, how the data will be treated and processed.
Customer:
- Wants categories for easy and speedy search
- Expects precise application of selected criterion like price, size, type
- Customer rating for products
- Selection of product and placing order
- Check price and delivery charges
- Move to cart and process payment
- Confirmation of payment and order booking
- Order dispatch details
- Order Cancellation
- Return window for the order
- Return, replace and refund
Supplier:
- Maintaining categories and descriptions for easy and speedy search
- Proper filters and sorting for conditions that match price, size, type
- Customer rating for products should include positive and negative comments and rating
- Selection of product and accepting order based on current stock
- Match price, delivery charges, and other delivery conditions
- Move to cart, temporary lock the inventory for selected order if in stock, take to payment gateway and process payment else cancel an order
- Sending confirmation of payment and order booking with details like date, order ID, amount, taxes, and then generate invoice
- Order dispatch details to include the order related all information and invoice, creating log once the product is delivered
- Order cancellation policy for processing refund before dispatch or product or while product is in transit
- Return window for the order for each product in terms of days within which it is returnable, in case of non-returnable product display no- return policy
- Return, replace, and refund in case of returnable products. Check if the replacement is available, is refund or replacement requested within the return window. Check if user is requesting replacement or refund, and select action accordingly. Respond with appropriate information for return pick up, replacement dispatched and courier details, refund issued and refunded to account details, etc.
BDD Tools:
- ACCELQ: A cloud-based test automation tool automates API and web testing. It has a powerful and flexible approach towards complex automation, involves Artificial Intelligence and no coding.
- TestProject: A free cloud-based test automation platform for all operating systems Android and iOS
- Hiptest: A continuous testing tool that supports BDD that gives real-time actionable insights.
- Cucumber: It allows writing BDD specifications in non-technical language to maintain the requirements and the test conditions.
- Jbehave an open source framework that creates text-based stories, this Java based framework runs on support of IDEs.
- Specflow: This open-source tool is .NET based and needs Visual Studio and IDEs.
- Selenium: An open-source web automation tool that supports multiple OS like Windows, Mac, and Linux.
Wrap Up:
Short descriptions of the product are the user stories that help others in planning for betterment of the product and end user’s experience. Though it cannot replace the requirement document, user stories can be of great use. The business context is the learning tool while accurate response to disinformation is a user story. Designing effective software to meet the precise thought of the customer is an acquirable skill. Behaviour Driven Development (BDD) offers technical insights and adds to the business intellect.
