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

We can borrow important principles from the context-driven school of testing when planning testing for each story, iteration, and release.

The value of any practice depends on its context.

There are good practices in context, but there are no best practices.

People, working together, are the most important part of any project’s context.

Projects unfold over time in ways that are often not predictable.

The product is a solution. If the problem isn’t solved, the product doesn’t work.

Good software testing is a challenging intellectual process.

Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

For more on context-driven testing, see www.context-driven-testing.com.

The quadrants help give context to agile testing practices, but you and your team will have to adapt as you go. Testers help provide the feedback the team needs to adjust and work better. Use your skills to engage the customers throughout each iteration and release. Be conscious of when your team needs roles or knowledge beyond what it currently has available.

The Agile Testing Quadrants provide a checklist to make sure you’ve covered all your testing bases. Examine the answers to questions such as these:

Are we using unit and component tests to help us find the right design for our application?

Do we have an automated build process that runs our automated unit tests for quick feedback?

Do our business-facing tests help us deliver a product that matches customers’ expectations?

Are we capturing the right examples of desired system behavior? Do we need more? Are we basing our tests on these examples?

Do we show prototypes of UIs and reports to the users before we start coding them? Can the users relate them to how the finished software will work?

Do we budget enough time for exploratory testing? How do we tackle usability testing? Are we involving our customers enough?

Do we consider technological requirements such as performance and security early enough in the development cycle? Do we have the right tools to do “ility” testing?

Use the matrix as a map to get started. Experiment, and use retrospectives to keep improving your efforts to guide development with tests and build on what you learn about your product through testing.

Summary

In this chapter we introduced the Agile Testing Quadrants as a convenient way to categorize tests. The four quadrants serve as guidelines to ensure that all facets of product quality are covered in the testing and developing process.

Tests that support the team can be used to drive requirements.

Tests that critique the product help us think about all facets of application quality.

Use the quadrants to know when you’re done, and ensure the whole team shares responsibility for covering the four quadrants of the matrix.

Managing technical debt is an essential foundation for any software development team. Use the quadrants to think about the different dimensions.

Context should always guide our testing efforts.

Chapter 7 Technology-Facing Tests that Support the Team

We use the Agile Testing Quadrants as a guide to help us cover all the types of testing we need and to help us make sure we have the right resources to succeed at each type. In this chapter, we look at tests in the first quadrant, technology-facing tests that support the team, and at tools to support this testing. The activities in this quadrant form the core of agile development.

An Agile Testing Foundation

We discuss Quadrant 1 first because the technology-facing tests that support the team form the foundation of agile development and testing. See Figure 7-1 for a reminder of the Agile Testing Quadrants with this quadrant highlighted. Quadrant 1 is about much more than testing. The unit and component tests we talk about in Quadrant 1 aren’t the first tests written for each story, but they help guide design and development. Without a foundation of test-driven design, automated unit and component tests, and a continuous integration process to run the tests, it’s hard to deliver value in a timely manner. All of the testing in the other quadrants can’t make up for inadequacies in this one. We’ll talk about the other quadrants in the next few chapters and explain how they all fit together.

Figure 7-1 The Agile Testing Quadrants, highlighting Quadrant 1

Teams need the right tools and processes to create and execute technology-facing tests that guide development. We’ll give some examples of the types of tools needed in the last section of this chapter.

The Purpose of Quadrant 1 Tests

Unit tests and component tests ensure quality by helping the programmer understand exactly what the code needs to do, and by providing guidance in the right design. They help the team to focus on the story that’s being delivered and to take the simplest approach that will work. Unit tests verify the behavior of parts as small as a single object or method [Meszaros, 2007]. Component tests help solidify the overall design of a deployable part of the system by testing the interaction between classes or methods.

Developing unit tests can be an essential design tool when using TDD. When an agile programmer starts a coding task, she writes a test that captures the behavior of a tiny bit of code and then works on the code until the test passes. By building the code in small test-code-test increments, the programmer has a chance to think through the functionality that the customer needs. As questions come up, she can ask the customer. She can pair with a tester to help make sure all aspects of that piece of code, and its communication with other units, are tested.