Agile Testing: A Practical Guide for Testers and Agile Teams

Good communication usually takes work. If you’re not taking enough opportunities to ask questions and review test cases, go ahead and schedule regular meetings to do so. If there’s not much to discuss, the meetings will go quickly. Time in a meeting for an insightful discussion can save coding and testing time later, because you’re more certain of the requirements.

High-Level Tests and Examples

We want “big picture” tests to help the programmers get started in the right direction on a story. As usual, we recommend starting with examples and turning them into tests. You’ll have to experiment to see how much detail is appropriate at the acceptance test level before coding starts. Lisa’s team has found that high-level tests drawn from examples are what they need to kick off a story.

High-level tests should convey the main purpose behind the story. They may include examples of both desired and undesired behavior. For our earlier Story PA-5 (Figure 17-2) that asks to show the shipping cost for 5-day delivery based on the order’s weight and destination, our high-level tests might include:

Verify that the 5-day shipping cost displays as the default as soon as the user enters a shipping address.

Verify that the estimated shipping cost matches the shipping cost on the final invoice.

Verify that the user can click a button to change the shipping address, and when this is done, the updated shipping cost displays.

Verify that if the user deletes items from the cart or adds items to the cart, the updated shipping option is displayed.

Don’t confine yourself to words on a wiki page when you write high-level tests. For example, a test matrix such as the one shown in Figure 15-7 might work better. Some people express tests graphically, using workflow drawings and pictures. Brian Marick [2007] has a technique to draw graphical tests that can be turned into Ruby test scripts. Model-driven development provides another way to express high-level scope for a story. Use cases are another possible avenue for expressing desired behavior at the “big picture” level.

See the bibliography for links to more information on graphical tests and model-driven development.

A Picture Is Worth a Thousand Words

The saying “A picture says a thousand words” can also be applied to test cases and test validations.

Paul Rogers [2008] has been experimenting with some cool ideas around this and explains his team’s approach to its problem in the following sidebar. Figure 17-3 shows the UI model he describes.

The application I work on is very graphical in its nature. It allows a user to modify a web page by adding “photo enhancements” such as glasses, hats, or speech bubbles to images, or by highlighting the text in the web page with a highlighter pen effect.

There is a complex set of business rules as to what additions can be applied to images, how and where they are affixed, and how they can be rotated. To explain the tests for these rules, it was much simpler to draw a sketch of a typical web page with the different types of additions and add small notes to each picture.

Text highlighting also posed many challenges. Most problematic were the areas where text highlighting covered only part of an HTML tag. To describe what should be expected in many different situations, we created different web pages and printed them out.

Using real pen highlighters, we highlighted the areas we expected to show as highlighted after starting and ending in certain areas. This way, we had an easy-to-read regression test.

Figure 17-3 Sample of UI modeling technique

Low-tech tools can take the mystery out of complex application design. Find ways to express business rules as simply as possible, and share those with the entire team.

Mock-ups can convey requirements for a UI or report quickly and clearly. If an existing report needs modifying, take a screenshot of the report and use highlighters, pen, pencil, or whatever tools are handy. If you want to capture it electronically, try the Windows Paint program or other graphical tool to draw the changes and post it on the wiki page that describes the report’s requirements.

See the sample mock-up of UI changes in Chapter 16, “Hit the Ground Running.”

Distributed teams need high-level tests available electronically, while co-located teams might work well from drawings on a whiteboard, or even from having the customer sit with them and tell them the requirements as they code.

See Chapter 9, “Toolkit for Business-Facing Tests that Support the Team,” for some ideas on tools to gather and communicate requirements.