- Agile Testing Quadrants
- Challenging the Quadrants
- Using Other Influences for Planning
- Planning for Test Automation
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Planning for Test Automation
Since Mike Cohn came up with his test automation pyramid in 2003, many teams have found it a useful model to plan their test automation. To take advantage of fast feedback, we need to consider at what level our automation tests should be. When we look at the standard pyramid, Figure 8-7, we see three levels.
)
Figure 8-7 Automation pyramid
The lowest level is the base—the unit tests. When we consider testing, we should try to push the tests as low as they can go for the highest return on investment (ROI) and the quickest feedback.
However, when we have business logic where tests need to be visible to the business, we should use collaborative tools that create tests at the service layer (the API) to specify them in a way that documents system behavior. See Chapter 16, “Test Automation Design Patterns and Approaches,” for more details. It is at this layer that we can automate at the story level so that testing and automation can keep up with the coding.
The top layer of the pyramid consists of the workflow tests through the user interface (UI). If we have a high degree of confidence in the unit tests and the service-level or API-level tests, we can keep these slower, more brittle automated tests to a minimum. See Chapter 15, “Pyramids of Automation,” for more detail on alternative pyramid models.
Practices such as guiding development with examples can help define what the best level for the test is. A team’s cadence can be set by how well they plan and execute their automation and how well they understand the level of detail they need. Consider also how to make your automation test runs visible, whether displayed in the continuous integration environment or on a monitor that is in the open.