Use Cases and ATDD/BDD Scenarios

Ivar Jacobson And Alistair Cockburn have a great article on “Use Cases are Essential”. You can read it at https://dl.acm.org/doi/pdf/10.1145/3631182. Its summary says, “Use cases provide a proven method to capture and explain the requirements of a system in a concise and easily understood format”. I have incorporated use cases in my ATDD/BDD workshops for many years. In this article, I’ll show one transformation of the use case they used in their paper into the detailed ATDD/BDD scenarios. 

The PDF is here

The HTML version is here.

The Full Story – Checking a Big Output

In “Building Collaboration with Visible Tests”, we saw how to write scenarios for three of the requirements of the FizzBuzz kata.  In this article, we’ll look at the remaining requirement – a big output and alternative ways to create tests for it using BDD and Approval Testing  (Llewellyn Falco and Emily Bache).   The same approaches can be used for other applications which have large amounts of output.     

PDF is here.

HTML is here.

The Auction Sniper – An ATDD/BDD Approach

In “Growing Object-Oriented Software, Guided by Tests”, Steve Freeman and Nat Pryce excellently present driving the development of an application with tests.   The example application on which they demonstrate their techniques has far more complexity than your typical TDD example.  That makes it a good example of showing some ATDD/BDD techniques that are not usually demonstrated in simple applications.

HTML is here.

PDF is here

Acceptance Testing Artificial Intelligence – AIQ

How do you apply test-first to an artificial intelligence application? That was a question posed to me during one of my ATDD/BDD workshops. Here are my thoughts. I got inspiration from recent articles in IEEE Spectrum and Communications of the AC. I welcome additional suggestions from you. The examples here represent some of the areas in which AI is currently used. Another article will explore acceptance testing for autonomous vehicles. 

Html is here. PDF is here.

How Do We Know We’re Done? One Way to End the Story

“How Do We Know We’re Done?” is a question often asked by agile teams.   I’d like to show a narrative of how this question might be answered.   As the example, I’ll use one from James Shore’s new edition of Art of Agile Development, Chapter 9, Customer Examples.  He describes a meeting between the product owner and the developers to gather information on a story  The section ends with the developer’s taking a picture of a whiteboard of a business rule and heading off to develop.    Here’s a possible narrative for the rest of the story of “How Do We Know We’re Done”. 

Html is here. PDF is here.

Building Collaboration with Visible Tests

Customer requirements that have outcomes visible to the user can use a testing approach that is readable to the Customer to decrease effort and increase collaboration.    The FizzBuzz Kata is a frequently used exercise to develop TDD skills.   We’ll show an alternative approach to the kata that focuses the visible output and provides an easy way to add variations from a tester’s perspective.   This approach can be used for any business rules and calculations that are specified by the customer or subject matter experts. 

Here is the html. Here is the pdf.