When I arrive at Phone2Action’s office every morning, I enter through a set of doors that prominently display one of the company’s core values: “Our customers are the reason we exist.” This greeting serves as a reminder to center the day’s tasks on the people who use our platform.
As a Civic Technology Fellow for the Quality Assurance (QA) team, my responsibilities involve performing checks for functionality. On a typical day, I’ll report bugs on Jira, write test scripts, and confirm that engineers’ fixes behave as intended.
This summer, the QA team is exploring various approaches to further streamline testing processes within our development workflow. Whether we’re engaging in traditional manual testing or evaluating the merits of new tools, we prioritize advocates’ needs above all else. Ultimately, we find that using Behavior-Driven Development (BDD) with Cucumber encourages company-wide collaboration to continually build and improve the features our clients value most, while ensuring our existing product offering remains robust.
BDD promotes approaching testing in terms of behavior, or what a feature does. In this way, it demands a complete understanding of customers’ core needs. Before developers begin writing code, teams across the company, from developers to product owners, must come together to deliberate over key scenarios that should pass for a feature to be successful. During these specification workshops, all stakeholders help write feature descriptions. This process eliminates the possibility of ambiguous requirements. Preventing miscommunication from occurring at a more critical time in implementation also results in smoother sprints and releases.
BDD also depends on clear documentation of such collaboration. To ensure that QA and engineering processes remain accessible to non-technical teams, companies increasingly opt to use plain business language for their test scripts. At Phone2Action, Cucumber has been a welcome addition to the QA team. With this tool, we’ve embraced writing feature files with the simple syntax of Gherkin and tying these to the execution code. These scripts thus serve as executable specifications. In our view, Cucumber is valuable for not only automating testing, but also providing for clearer communication across the company.
As an example, say a company develops kiosks that dispense tickets at transit stations. Its stakeholders convene at a specification workshop to discuss adding value to a bus pass with cash. They agree on certain test cases that represent the crucial scenarios in which this feature must work. Collaboratively, they write the following:
This file focuses on a single feature, using cash to add value to a bus pass. Though it includes only two scenarios, we can imagine writing relevant additions as further development is planned — attempting to feed in a $50 bill and being informed the highest acceptable denomination is $20, for instance. While the QA team translates feature files into step definitions, all teams can edit these test cases with ease. Above all, Cucumber ensures that everyone across the company has transparent access to living and executable documentation.
Phone2Action’s mission parallels that of BDD. In powering grassroots movements, we recognize that all voices are imperative to shaping public policy. Similarly, our approach to testing invites all stakeholders to exchange ideas with one another. The diversity of our clients and their respective goals necessitates thoughtful software development. We can respond to advocates’ needs from multiple angles when teams with varied skillsets contribute to the development process. To this end, Cucumber has been a promising tool in consolidating acceptance tests, functional requirements, and software documentation. After all, our customers are the reason we exist — and collaboration through BDD is a major reason our advocacy platform is constantly improving.