Dear QA Friends,
In this article I’ll be sharing how BDD techniques are helping me in optimising manual and automation testing which resulted in pushing newer software updates at higher pace and lesser bugs than traditional testing techniques.
I have been involved in QA since October 2002, having started with manual testing, later jumped into web, mobile, api automation & usability testing. In my current startup; I do all of these testing activities. Last year I attended a BDD & Cucumber workshop with Matt Waynn. After attending the workshop I started practising those lessons in my current startup & have seen tremendous benefits.
How BDD helps in Engineering Quality rather than Assuring Quality
Before my current startup, I have seen “You Burn, I’ll Scrape” happening in almost all of the projects. What does this mean?
W. Edwards Deming had made this statement on U.S. automobile companies’ culture who believe in “Make & Inspect”. Edwards was involved with the Japanese motor industry after the second world war in an effort to help build its economy. Japanese automobile companies believe in building quality into the product and thus reduce defects, cost & wastage.
How does this apply to the software testing industry?
Developers write bugs, QA find some of those bugs, the Project Manager (PM) prioritises some of some of those bugs. This cycle continues until the PM thinks the product is in OK state to be delivered to the customers. Thus developer gives the “burnt toast” to QA, which QA keep on “scraping” till PM says it looks OK to be given to customer.
With BDD techniques the whole team can avoid burning toast and instead build quality into the product from day 1.
How does BDD work? What is “3 Amigos Session” & “Example Mapping”?
BDD starts with regular “3 Amigos Session”. This is short & effective meeting between PM, Dev & QA where they do “Example Mapping” exercise to come up with all the rules of particular features with concrete examples against each of the rules to add more clarity. For example, a PM or BA asks to deliver calculator mobile app which does summation of two numbers. Now with “Example Mapping” exercise in “3 Amigos Session”; we come up with the below rules.
- It can do a summation of fraction numbers.
- The minimum number supported is 0.01 and maximum number supported is 99.99
- It can’t do summation of negative numbers
- It takes voice inputs of siri and google assist etc. see here
The main goal of “3 Amigos Session” is doing “Example Mapping” and writing down all the user stories in Given When Then format so that all engineers in the team have a clear understanding of what needs to be delivered to the customer.
This way we add quality into the code from day 1 and avoid burning toast.
You can write user stories during this meeting or later as well. At least make sure all 3 amigos have agreed upon Rules to be coded in the upcoming sprint.
BDD -> TDD -> Test Pyramid
Now on you can follow TDD approach by QA and developer. QA can have the discussion with the developer if a particular story/part of it can be at Unit level. Thus you are trying to follow “Test Pyramid” as well.
Once you decide on stories which can be automated at Unit/ Integration ( API ) / UI level then start with automation. QA can take care of API, UI automation.
As the sprint progresses you can easily track how stories are being progressed. At this moment the “Cucumber” tool becomes very handy.
With “Cucumber” tool you can create a bridge between “User Stories” & “Code” which will execute that story. If you compare this approach against tradition test cases writing & automating there are a few differences. There is no direct connection between these 2. It is hard to maintain, debug and report how much % of user stories being automated.
Here are some links that you might find useful for Web Automation with Cucumber + Selenium and Mobile Automation with Cucumber + Appium
Living Documentation > No More Test Cases Management Tool
One more best part of BDD is “Living Documentation”. You have written User stories and corresponding test cases which certifies those user stories. Now with this model in place, you are sure that any given time all the user stories are still applicable, updated & valid against traditional testing where there is no connection between test cases and automation script, hardly any way to confirm which test cases are still valid in particular sprint. Try out the Yard Extension that adds Cucumber features.
Are you a QA Waiter or Assistant Cook?
Now you decide if you, as a QA are doing a waiter’s task or Assistant Cook’s role with help of BDD?
With traditional software development the QA waits for the developer to give them the build, which needs some testing and then is delivered to customer. With BDD; QA is involved from day 1 in discussing, clarifying & writing user stories with PM and building quality into the product along with developer.
