Crispin, Lisa - Agile Testing - A Practical Guide for Testers and Agile Teams

Chapter 9 Toolkit for Business-Facing Tests that Support the Team

In the previous chapter, we talked about how to approach business or functional testing to support the team in its effort to build the right software. In this chapter, we’ll examine some of the tools you can use to help your team succeed with Quadrant 2 tests.

Business-Facing Test Tool Strategy

How do we capture the business-facing tests that help the programmers know what to code? Face-to-face conversations between programmers and customers are usually the best way, but even when customers are part of your team, they don’t have all day to hang out with programmers and explain features. If any customer or developer team members are in different locations, impromptu hallway conversations might not be feasible. Besides, six months from now, we might want a way to remember why we coded a piece of functionality a certain way. If some of our team members are in different locations, we’re definitely going to need some way to share information electronically.

As agile development has gained in popularity, we have more and more tools to help us capture examples and use them to write executable tests. The tools available are changing too fast for us to include an inventory of them in this book, but we can offer some examples of tools and some strategies for using them to help provide business-facing tests that support the team’s development of new stories. Some of the tools we discuss here aren’t new, or specific to agile development, but they work well in an agile project.

Your strategy for selecting the tools you need should be based on your team’s skill set, the technology your application uses, your team’s automation priorities, time and budget constraints, and other concerns unique to your situation. Your selection of a tool or tools should not be based on the latest and coolest tool offered by a salesman. You might need many different tools to solve different problems.

For more information about a general approach to test automation, see Chapter 14, “An Agile Test Automation Strategy.”

We encourage customers to do some advance preparation and to be ready to explain examples for each story during iteration planning. Testers are in a good position to help customers figure out how to provide the right amount of detail at the beginning of the iteration. It’s hard to strike just the right balance.

Lisa’s Story

Soon after our team chose to use FitNesse for specifying and automating business-facing tests, our product owner and I tried to make good use of the new tool. We had an extremely complex epic coming up. We spent many hours writing detailed test cases for highly complex business rules weeks in advance of the iteration where the first story of the epic was started. We felt good about getting a running start on developing the new functionality.

When they started working on these stories, the programmers complained that they couldn’t get the big picture from these detailed tests. The tests were also designed in a way that was incompatible with the actual code design. I ended up spending hours refactoring them. It wasn’t a complete waste of time, because at least I understood the stories well and we had a number of test cases we could use eventually, but it wasn’t the right approach for our team. Trial and error has shown us that high-level tests combined with a few examples of desired and undesired behavior are the best way for the programmers to know what to start coding.

—Lisa

Experiment with different levels of up-front detail in test cases to figure out what works best for your team. Whatever level of detail you’re after, you need some way to help customers find and express examples of desired system behavior. In the next section, we look at the types of tools that can do that.

Tools to Elicit Examples and Requirements

As we pointed out in Chapter 8, stories are only a starting place for a prolonged conversation about the desired behavior. Having correctly sized stories where the feature, user, and purpose are clearly stated gives us a head start. They aren’t very detailed, because as Mike Cohn [2004] points out, it’s best to defer collecting details until the story is included in an iteration. Collecting details for a story that might never be included is a waste of resources. We like the “role, function, business value” pattern for user stories that Mike Cohn describes in User Stories Applied , as in:

As a (role), I want (function) so that (business value).

This format doesn’t work for everyone, so we encourage you to experiment and see what works best in your situation. Regardless of how your user stories read, you need some way to flesh those stories out with examples and business-facing tests that guide development.

One simple story can have a wide-ranging impact, not only on the application, but across the organization, its clients, its associates, vendors, or partners. If we change an API, we have to notify any customers or vendors who might be using it. If we plan a UI change, we want, or might even be contractually obligated, to give a certain amount of advance notice to users. Stories may affect legal concerns or impact external reporting. New features often mean new or updated documentation. Of course, changed functionality is likely to affect other parts of the system.

The software development team, including the testers, should help the customer capture and communicate all of the requirements related to each story or theme. Developing new features, only to be prevented from releasing them for legal reasons or because a business partner wasn’t informed in time, is a frustrating waste of time (just ask Lisa!). Lean development teaches us to avoid waste while we develop software.

What tools can help us illustrate desired behavior with examples, brainstorm potential implementations and ripple effects, and create requirements we can turn into tests? Some examples are:

Checklists

Mind Maps

Spreadsheets

Mock-Ups

Flow Diagrams

Software-Based Tools

The list includes a number of simple tools that aren’t unique to agile testing but that shouldn’t be neglected. In agile development, simple solutions are usually best. Let’s look at these in more detail.

Checklists

Checklists are one way for product owners to make sure they correctly assess and communicate all of the aspects of a story. The product owner for Lisa’s team, Steve Perkins, came up with his own “story checklist” to make sure he and the stakeholders think through everything affected by the story. He created a template on the team wiki for this purpose. The checklist specifies the conditions of satisfaction—what the business needs from the story. It also includes impacts on existing functions such as the website, documents, administrative forms, account statements, and other components of the system and the daily operation of the business. The checklist makes sure the team doesn’t miss requirements such as data migration, notifications, legal considerations, and communications to vendors and business partners because they forgot to consider them. Figure 9-1 shows a sample story checklist.