I’ve heard a lot of enthusiam for Behaviour Driven Development and seen a number of talks on the matter. However every time I dive into the subject, it leads into creating automated tests and my work is primarily with manual testing.
Nonetheless I am fascinated by the topic and am keen to explore how we can take some of the concepts of BDD and apply them to manual testing.
When I first started learning about BDD it was as part of a talk on Gherkin. Given I’m not overly fond of very rigid language structures in documentation (or at least no scope to deviate when applicable), I didn’t initially show a lot of interest, however over time I’ve changed my thoughts.
To start with, we are defining both requirements and the tests at the same time. Whilst all the material I’ve seen ends in tying this to automated tests, why can’t this also be manual testing?
Speaking with another test engineer recently, they commented on how they found existing test specifications a better source of describing behaviour than our UCMs (if the docs exist for that product). It did strike me a little – we’re writing requirements in User Stories, then updating our UCMs and then our test specs. Our unit tests also define the behaviour, although as a test engineer I am not exposed to them in our usual working processes.
BDD seems to solve this by defining the behaviour and using that as the definition for your test. Whilst sometimes a Gherkin scenario won’t fully explain what to do, in many (or most) test cases it does. I do question whether a test entitled “Log in with valid user credentials” needs 5 steps explaining how to log in with pre-conditions of not being logged in. If the behaviour is clearly explained (especially when using more “real world” examples), that is what I’ll test doing. These are my test cases.
A common exercise in BDD, Example Mapping, is also very interesting. Often testing for a User Story might take the acceptance criteria and map it to a test task, with some test cases created as a result. However using Example Mapping and the knowledge in the User Story and any other requirements docs can help us define great test cases and/or data sets.
I’m keen to give this a shot when I return to work. Whilst clearly it is an exercise that is intended as a planning exercise for a team, I can see the usage as an individual test engineer. I’ll even use the output of this to create a load of TestLink test cases, possibly using Gherkin a shot within the description, only including steps if actually essential.