Some testers worry that BDD automates them out of a job. In reality, BDD gives testers a bigger role, not a smaller one. Testers move from checking finished work to shaping it before it is built.
This article explains what testers do at each stage of BDD. For the full process and tooling, see this reference on behaviour driven development bdd for testers.
The tester in discovery In a Three Amigos session, the product owner brings business value and the developer brings implementation. The tester brings risk. Your job is to ask the questions nobody else asks:
<!--[if !supportLists]-->• <!--[endif]-->What happens if the input is empty?
<!--[if !supportLists]-->• <!--[endif]-->What if the user does this twice?
<!--[if !supportLists]-->• <!--[endif]-->What if the downstream service is slow or down?
<!--[if !supportLists]-->• <!--[endif]-->What are the limits, and what happens just past them?
Every answer becomes another example, and often another scenario.
The tester in formulation
Testers are often the best people to turn examples into Gherkin. You already think in preconditions, actions and expected results, which maps directly onto Given, When and Then.
Scenario: Withdrawal exactly at daily limit succeeds
Given the daily withdrawal limit is 1000
And the customer has withdrawn 0 today
When the customer withdraws 1000
Then the withdrawal should succeed
Boundary scenarios like this one are exactly where testers add value.
The tester in automation
Depending on the team, testers may write step definitions themselves or pair with developers. Either way, testers keep the suite healthy by spotting duplicated steps, flaky scenarios and slow tests.
Testing beyond the scenarios
BDD scenarios cover agreed behavior. They do not replace exploratory testing, performance testing or security testing. Testers still own those, and they often uncover new examples that feed the next discovery session.
Skills that help testers in BDD
<!--[if !supportLists]-->• <!--[endif]-->Domain knowledge: understanding the business rules you are testing.
<!--[if !supportLists]-->• <!--[endif]-->Clear writing: scenarios are read by non-technical people.
<!--[if !supportLists]-->• <!--[endif]-->Basic coding: enough to read and write step definitions.
<!--[if !supportLists]-->• <!--[endif]-->Facilitation: keeping discovery sessions focused and short.
Frequently asked questions
Do testers need to code in BDD?
Basic coding helps, especially for step definitions, but the most valuable tester skills in BDD are questioning and clear writing.
Does BDD replace manual testing?
No. Exploratory testing remains essential for finding issues nobody predicted.
Final thoughts
In BDD, testers move upstream and influence quality before code exists. To reduce time spent writing regression tests by hand, generate them from real API traffic. Explore Keploy API testing.
Top comments (0)