Previously
This is the ninth in a series about TDD’s value to humans, following
- Keeping my job, in which I lost my manager’s trust,
- A last-minute feature, in which I regained some,
- Deadline pressure, in which I earned quite a bit more than I’d started with,
- Continual delivery, in which the circle of trust grew to include our Operations team,
- Fail-safe, in which we were always deploying soon,
- A big project, in which we delivered an 8-month project with minutes to spare,
- Win-win, in which we helped another project hit the same deadline, and
- No secret, in which people oddly found the reasons for our success disappointing
A growth opportunity
Our team had solidly established the habit of writing good tests first and listening to what they told us. People who could read Perl could read our tests, and we’d taken full advantage of that to build shared understanding with stakeholders of sufficiently technical backgrounds, whose trust served to reinforce the effectiveness of our collaboration and our product. We knew how valuable it’d be if we could find a way to extend that understanding and trust to a broader audience. We were on the lookout.
When our product and team moved to a better-fitting department, our team’s reputation garnered some attention from our new neighbors. For the first time, we found ourselves living next to a group of QA folks, whose perceptive manager saw us as an opportunity. His more skilled people could help us and learn from us. Would I like to borrow one of them for a full two-week iteration?
Unlike previous occasions when I’d been offered a person on short-term loan, I instantly had a pretty good idea how we could put a skilled tester to effective use. But not yet. First, we needed to prepare.
Our preparations
Our TDD practice was already oriented toward system behavior, aimed at uncovering not only design choices but also acceptance criteria. We would usually find surprising ramifications of a chosen approach early in development, while it was still relatively cheap to review with stakeholders and either get more precise agreement or adjust the goal. We wanted our borrowed tester to comfortably participate in those conversations and potentially contribute test scenarios. We now needed a language more shared and more commodious than Perl. And we didn’t need — indeed, couldn’t afford — to start shlepping around any manual tests or non-executable specifications on our journey. Dear reader, you doubtless see what we saw: Gherkin could be our shared language, and Cucumber could incorporate it into our build.
There was one small problem: none of us had ever used Cucumber before. We didn’t want to waste any of our tester’s limited time figuring out how to wield a new tool. We wanted to be ready the moment he arrived. So we immediately picked a feature perfect for learning: a low-urgency feature intended for the benefit of our compatriots in Operations, and whose desired behavior we understood very well. Instead of confidently writing our usual tests, we wrestled with how best to express our assertions in Gherkin-inflected English, and how best to arrange for them to fail meaningfully against the production code we were wanting to change.
When we got it figured out well enough, with Cucumber hooked into the build, we asked Ops to review the spec with us. Because they could! And maybe they’d spot something we’d misunderstood! When they didn’t, we proceeded to test-drive as usual, albeit with slightly different red-test messages; when we got to green, the feature was every bit as done (and well done) as usual.
The payoff
We were ready for our tester. When that iteration kicked off, we would set right to pair-writing scenarios, likely conjuring more meaningful tests than we’d have done on our own, and our visitor would be acquiring a new and marketable skill.
Or at least he would have, if the window of opportunity hadn’t been rudely slammed shut.
A change of plans
The original offer, and our preparatory actions to take advantage of it, occurred while product decisions had still been mine — which is to say, when the team had opinions distinct from mine, I generally listened and took them into account. But I was in transition to a much-needed role as an internal Agile coach, so my team and product were necessarily in transition too. By the time the promised iteration rolled around, product decisions were no longer mine — which turned out to mean they were made with very limited consideration for the team (me included).
The new product manager promptly nixed any further efforts with Gherkin as a language, Cucumber as a tool, and QA as a partner in our development process. No reason was ever shared with us for this decision, which we felt wasted our investment in time and effort, ignored our needs and wishes, and limited our options for improving our effectiveness.
Conclusion
Cucumber continued to be the test runner for that lone Ops feature. But who knows how much it might have helped us collaborate more productively with testers, non-technical managers and customers, and the business as a whole? We never got the chance to find out.