Gojko Adzic

There is a discussion on the UK agile testing mailing list on driving the development of an administrative application with BDD. It illustrates a problem that many teams have, so I’ll post my response here as well.

Although we have a long way to go things are going OK at the moment and we feel it is bringing some real focus to the development process. However a lot of the early stories are largely admin type CRUD – for
example functionaility to set up user defined entities and their user defined properties within the system and to provide a mechanism for relating these entities to each other
…
Does anyone have any advice about how to write tests for this sort of stuff or any experiences in starting out with BDD they can share.

CRUD is not a user story, it’s a screen. It’s not a business function, but implementation detail. Why do the business users need a particular CRUD screen? (I know it sounds as a stupid rhetorical question, but I’m serious) What does it allow them to do?

Often you don’t need to implement an entire CRUD screen and deliver them one by one. Sometimes there is value in releasing two screens that allow you to set a subset of properties but together they bring value. You can then automate these tests through the UI and use the CRUD screens, but that will be hidden in the automation layer. Say for example that we have a risk report that lists users and their card numbers:

Scenario: Only regular customers with a specific risk category and 
              card type show up in risk reports
Given the following users
|name| type| card type| card number| risk category|
|Mike |VIP | Mastercard |53111 11111 11111 1111|X|
|Tom |VIP| Visa |41111 11111 11111 1111|Y|
John |Regular |Mastercard |51111 11111 11111 1111|X|
|Steve |Regular |Mastercard |52111 11111 11111 1111|Y|
Then the risk report for Mastercard and category X contains the following data
|John | 51111 11111 11111 1111|

This could, for example, invoke the user CRUD to save a user name, type and risk category and a completely different CRUD to save card details for that user. Any other information that would go on that CRUD (addresses, card expiry dates etc) aren’t part of this story or criteria because they are not important for this particular report.

Start with the outputs, the reports that the system produces, instead of data entry operations. this ensures that you have the data you need to produce the reports at the end, and that you don’t have superfluous data that nobody really cares about. if you don’t do that, the resulting data schemas are often overcomplicated and contain many things that simply aren’t used at the end at all.

Speaking at the BBC QA Day today, Liz Keogh said that learning is often a constraint on software projects. Software projects deal with many risks and unknowns as they are mostly about new product development. Doing a project which took eight months again, with the same people and same technology, would take two months said Keogh, explaining that people would be much more efficient as they have already learned everything they need. One of the key ideas in lean software development is not to go faster than their main constraint and trying to help that constraint. Missing an opportunity to learn is waste, said Keogh, adding that focusing on learning as much as possible can help projects move much faster. Continue Reading »

Here’s the video from my talk on Behaviour Driven Development and Acceptance Testing with Cucumber last week. In this talk, I go over the basics of Cucumber scenario structure and integration and show examples of using it with Ruby, .NET and Java applications. (scroll down to see the slides and links from the presentation) If you’re interested Cucumber or Behaviour-Driven development, also check out my new Introduction to BDD and Hands-on BDD with Cucumber workshops.
Continue Reading »

I got this question from a reader today:

How would you effectively define a sufficient set of If-When-Then scenarios to test for correctness what is potentially an extremely large set of transformations?

Continue Reading »

In part 2 of this tutorial we used tables to organise scenario information efficiently. This works fine for processing lists of objects, but it requires additional code to work with Cucumber tables and it isn’t the best solution when things go wrong. In this part, I’ll show you how to save even more time and effort when working with repetitive scenarios. Continue Reading »