Is BDD testing? Part 3 - Outside-in development and how testing fits
In parts 1 and 2 of this series I introduced a model that I created to help me understand behaviour driven development (BDD), shown below. I also discussed the collaboration side of the model and the role of testers within that, all with the intention of answering the question: is ‘BDD’ testing? In this post, I want to look at the outside-in development side of BDD and explore how testing fits into it.
Outside-in development
It seems to me that ‘outside-in development’, which I will refer to as OID from now on, is what confuses testers most. Essentially, OID works by using automation tools combined with scenarios from a collaborative session, to create a guide for developers. This results in ensuring developers develop what the business wants. The process is formed of three states, which you can see in the model above, but let’s look at each state in more detail:
Red state
A developer starts on the ‘outer wheel’ by using a Gherkin-based tool to tie explicit user actions to the step of a scenario which makes it impossible to execute that scenario (because the feature doesn’t exist). For example, a developer may use Cucumber to trigger a series of Selenium WebDriver actions on a browser, to simulate how a user would execute a scenario.
Green state
The developer will then move into the ‘inner wheel’ and run a similar red, green and amber process on a lower level. The developer will use this pattern against individual methods using a different unit level automation tool multiple times to get all the production code working. This, in turn, provides code that means the ‘outer wheel’ automated scenario can be executed without issue.
This process ensures that the developer has delivered what is the business expects, as well as informing the developer when they are done.
Amber state
The developer is now able to refactor their code and be informed if their changes are no longer delivering what the business expects.
Business-guided development
“If I could change one word in BDD it would be driven to guidance” (Dan North)
I’ve been very careful not to mention testers, tests or pass/fail in the above description. That’s because OID is not about testing, it’s about guidance, and this is what testers get wrong. The assumption among testers is that because OID uses tools that are typically related to automated testing, that must mean OID is automated testing.
OID is an evolution of acceptance test driven development (ATDD) and test driven development (TDD), which means it has inherited some misconceptions from ATDD/TDD. Testers struggle with ATDD and TDD, believing it’s a testing approach rather than a design process. This isn’t helped by the word ‘test’ existing in both names, which adds to the confusion.
However, testers should be aware that test automation tools are not exclusively used for test automation, they can be used for other things. Much like you can use a screwdriver in its traditional way, but also use it to open a can of paint. Yes, these approaches use test automation tools but they are using them as a means to keep the developer honest. OID helps developers design good code and deliver what the business really wants; not deliver testing.
Conclusion (so far)
In my first post of the series, I talked about how I struggled with BDD as a concept. More specifically it was OID that I struggled with the most. The assumptions and errors I’ve claimed testers make are all ones I’ve made personally, thinking that OID, ATDD and TDD were testing approaches when they are not. However, as I created my model I began to realise that OID is a development practice and not testing. That said, testers can support developers by pairing with them during the OID process to ask questions, give information about the application and observe what is being created for future testing.
So what does that mean for test automation? Surely, we need good test automation in place to help testers deal with the mountains of work we regularly face? Yes, we do need test automation but it should sit alongside the work done by OID, not be replaced by it. They both have very different concerns. OID focuses on guiding development, whereas test automation focuses on supporting testing in terms of rapid feedback and executing actions. Attempting to cover all those actions with OID results in a process that can neither deliver guidance (because of the noise generated), nor can it provide robust test automation (because the tools used aren’t the right ones for the job).
Originally published at www.hindsightsoftware.com.
