From Manual Testing to BDD in Mobile App Development

Over our seven year history, we have evolved our software development and QA processes significantly. We started app development knowing mobile was the future, but back then our QA process was decidedly retro. We manually tested our software on each device, plodding through the same test scripts over and over in iOS on a host of Android devices. Aside from being incredibly tedious, this manual process increased the price of our services and, most importantly, slowed development.

Manual Woes

As Android moved from a marginal to major player, fragmentation slowed QA speed further. With our move from waterfall to Agile, manual testing showed two more major flaws:

1: Software needed to be iteratively tested on both platforms and all devices throughout the course of the sprint. QA wasn’t able to keep pace, which limited their ability to test for the more insidious bugs excellent QA leads are great at rooting out.

2: QA needed to interpret and translate user stories into test scripts. But since QA was completely downstream and not part of the story development process, they were forced to translate each story into proper test scripts. This created huge translation risks. Plus, QA had to constantly monitor the storyboard and adapt as changes occurred. This led to wasted cycles testing outdated stories and a feedback delay from not testing changes immediately.

Enter BDD

With BDD, QA went from a downstream interpreter to an upstream contributor. Automated BDD scenarios freed QA to focus on edge case bugs that can become huge issues in live production environments. But BDD’s automated testing is not the only thing BDD allowed us to do well. BDD creates a common, plain English-based language to communicate features seamlessly with all members of the team – from Product Owners, senior leadership and Tech Dev, to Creative and QA.

Like most beginnings this wasn’t without its problems. Our scenarios, like those of many BDD novices, were imperative (highly detailed, long, complex and overly specific). Since they were overly detailed clients and internal resources saw BDD as tedious, complex and prone to error.

BDD Evolved

Once we made the shift from imperative to declarative we were able to write fast, simple and clear non-technical scenarios that told our team exact what to build instead of exactly how to build it. With this shift we were able to take full advantage of BDD to unify communication, automate testing and streamline Agile development.