Agile Testing: A Practical Guide for Testers and Agile Teams

Each agile team must find a process of writing and automating business-facing tests that drive development. Teams that automate only technology-facing tests find that they can have bug-free code that doesn’t do what the customer wants. Teams that don’t automate any tests will anchor themselves with technical debt.

Part IV, “Test Automation,” will guide you as you develop an automation strategy.

Quadrant 2 contains a lot of different types of tests and activities. We need the right tools to facilitate gathering, discussing, and communicating examples and tests. Simple tools such as paper or a whiteboard work well for gathering examples if the team is co-located. More sophisticated tools help teams write business-facing tests that guide development in an executable, automatable format. In the next chapter, we’ll look at the kinds of tools needed to elicit examples, and to write, communicate, and execute business-facing tests that support the team.

Summary

In this chapter, we looked at ways to support the team during the coding process with business-facing tests.

In agile development, examples and business-facing tests, rather than traditional requirements documents, tell the team what code to write.

Working on thin slices of functionality, in short iterations, gives customers the opportunity to see and use the application and adjust their requirements as needed.

An important area where testers contribute is helping customers express satisfaction conditions and create examples of desired, and undesired, behavior for each story.

Ask open-ended questions to help the customer think of all of the desired functionality and to prevent hiding important assumptions.

Help the customers achieve consensus on desired behavior for stories that accommodate the various viewpoints of different parts of the business.

Help customers develop tools (e.g., a story checklist) to express information such as business satisfaction conditions.

The development and customer teams should think through all of the parts of the application that a given story affects, keeping the overall system functionality in mind.

Work with your team to break feature sets into small, manageable stories and paths within stories.

Follow a pattern of “write test—write code—run tests—learn” in a step-by-step manner, building on each pass through the functionality.

Use tests and examples to mitigate risks of missing functionality or losing sight of the big picture.

Driving coding with business-facing tests makes the development team constantly aware of the need to implement a testable application.

Business-facing tests that support the team must be automated for quick and easy feedback so that teams can deliver value in short iterations.

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.