The Use Case Foundation article defines use cases and the principles behind them and gives an example of use case. This article shows the relationship between a use case and Behavior Driven Development / Acceptance Test-Driven Development (BDD/ATDD) scenarios.
HTML is here.
PDF is here.
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.
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.
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
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.
“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”.
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.
Following the ideas in One Model for Effective Software Development, this article presents one model for an Effective Inter-team Process. It provides an overview of the value delivery process (e.g., developmental value stream) for a software project that requires multiple teams.
Html is here, PDF is here.
The spreadsheet is a simple analogy to allocate responsibilities for many organizational and design decisions you need to make. Responsibilities can be assigned by rows, by columns, or by some combination of the two. The spreadsheet conundrum gives you suggestions on how you can do that assignment.