In this video, Meaghan Lewis shares the principles of the agile testing quadrants. The agile testing quadrants are used to classify different types of tests and their focus. The goal of the testing quadrants is to help a team determine which type of tests to implement.
- [Instructor] There are so many different types of automated test, unit, integration, component, functional, UI, and the list just goes on and on. Deciding which test to include for a project can be a difficult task. Luckily, there are some models that are extremely valuable, when determining which type of test to automate. One model that I recommend using, is the agile testing quadrants. The agile testing quadrants are used to classify test.
The quadrants have been helpful over the years for teams, as they plan the types of tests they want to implement. It also helps teams identify the resources necessary to accomplish that task. This model was developed by an agile testing consultant, Brian Marick, back in 2003. There are four distinct quadrants, separated by the x and y axis. On the bottom, there are technology-facing test, and on the top, there are business-facing test.
On the left-hand side, there are tests that guide development, and on the right, there are tests that critique the product. These quadrants define four areas to better classify different types of test. Now, let's talk about what each quadrant means. I'll start with quadrant one in the lower, left-hand side of the matrix. This quadrant describes technology-facing test, that guide development. These types of tests are always automated, and they ensure the functionality is working as expected, and that the code has a quality foundation to build upon.
Examples of tests that fall into this category, are unit test, integration test, and component test, all of which confirm the code is working as intended. This is a very important quadrant, and the most number of tests should be written in this area. Tests in quadrant one are written alongside development, and help to confirm the functionality of the feature as it's being built. Moving up to quadrant two in the top, left-hand side, describes business-facing tests that guide development.
These tests can either be automated or manual. They help answer questions and discover information about the application. The results of these test help validate the features of an application. Examples of automated test that fit into this category are functional and UI test. Manual test in Q Two use models like prototypes or mock-ups, and can include more high-fidelity prototypes, such as complete web pages. Tests in quadrant two are likely performed during and after development.
The automated test here should be included in the definition of done for a story to know when a feature is complete. These tests will also help to uncover bugs and issues in the application before releasing the software to the public. Moving over to quadrant three in the top, right-hand side, includes business-facing test that critique the product. This quadrant includes mainly manual test, but can benefit from automation as well. The tests here provide feedback about the current state of an application and whether or not, things are working as expected.
They are user-oriented and help to understand the user's experience by how they interact with the application. Quadrant three involves critical thinking and an in-depth observation of the application's workflows. Examples of test in this quadrant, include exploratory testing, usability testing, and A B testing. Test in quadrant three can be performed either before or after development is complete.
The purpose is to provide information, about what can be improved in workflows in the application. And finally, quadrant four, on the bottom, right-hand side, has test which are technology-facing, that also critique the product. These tests are all automated and are built with the help of specific tools. Their purpose is to provide targeted information about the application. Examples of tests that fall into quadrant four are performance test, load test, security test, reliability test and so much more.
Likely all of the tests that end with -ility, falls into this category. Quadrant four test are performed based on priorities of what is most important in the application. For example, a fast, page-load time is important, then it is probably a good idea to implement performance testing. These tests measure data which can then be analyzed, quantified, and visualized in some way. There are no hard rules about what type of test, must go into what quadrant, and what tests are necessary to a software project.
It is really all circumstantial. In addition, the quadrant-numbering system, does not imply any kind of order. There can be a focus on implementing quadrant two tests first, and then quadrant one or vice versa. It also doesn't require that there must be tests implemented in each and every quadrant. The goal is to understand that there are many different types of tests, that are either automated and manual, and to identify what are the most important types of tests to implement.
Use the test quadrants to guide your team when discussing which tests should be implemented for a particular software development project. Continue to think through the quadrants, as your team does planning, development, and releases, so that your whole team understands the importance of testing.
- The test pyramid
- Unit, integration, and UI tests
- Creating an automation strategy
- Choosing test tools
- Deciding what to automation
- Identifying the risks and cost of automation
- Implementing test automation
- Using continuous integration
- Measuring code coverage