Agile Testing Quadrants: Technology-Facing Tests That Support the Team (Q1) | David Tzemach
Updated: Mar 3, 2022
The first quadrant (Q1) is associated with automated testing and covers test types like unit tests, component tests, and API testing. This quadrant is essential to the overall development cycle because it allows the team to test the internal quality of their code.
The tests associated with Q1 help the team understand their code, what needs to be done, and how to design for maximum efficiency. Moreover, running unit, component and integration tests helps the team focus on one user story at a time and use the simplest development approach that can possibly work.
The use of Q1 tests is vital in the Agile environment. Still, to maximize their efficiency, the team should use TDD as a development approach, as it forces programmers to understand the behaviour of their code as they write the tests that will approve it.
Using this approach of tests first, programmers can develop their code only after they have thought about the functionality and asked questions (directly of the customer or any other team member) that remove uncertainty and ensure that the functionality meets customer needs.
The Importance of this Quadrant to the Overall Quality of the Product
Improves and validates code, architecture, and design.
Helps the team verify that their architecture decisions are valid.
Coding practices such as TDD free testers to focus on complex test scenarios instead of spending their time finding low-level bugs.
It is the foundation of TDD and CI frameworks that give the team instant feedback about the internal quality of their code.
Enables the team to reduce future technical debt.
Continuous build systems running unit tests reduce the number of failed builds and notify the team of failure within minutes of the code check-in.
Helps programmers confidently change their code without worrying about making unintended changes that adversely affect the system.
Where Are We No Longer Running Technology-Facing Tests?
Testing the internal code is the foundation of producing high-quality code that will be the baseline for future development and testing activities. However, a customer waiting for the product at the end of each sprint will not allow the team to invest endless time in this type of test.
This is where I often see the Product Owner start to interfere and ask for explanations why the team is spending their time testing the internal code instead of concentrating on business-facing tests that cover quadrant one tests. This is misguided because each quadrant has different purposes and goals.
The main difference is that Q1 tests allow programmers to run independent tests on their code and receive fast feedback, making them feel more confident about it. When a unit test fails, the programmer can easily understand the source of the failure and quickly fix it. Business-facing tests for the story define more information, making the testing more complex than the unit level (user interface, error handling, etc.).
The business-facing tests are for testing more complex user scenarios based on the customer point of view. These tests mainly focus on delivering a good experience to the customer. Therefore, the tests are more complex and take more time to execute.
Where is the line? It depends on the project and its constraints. Still, in my experience, you can stop these tests only when you have the confidence that the code has good coverage that guarantees no critical issues at the advanced phases of development. I use a simple rule stating that you should automate as many tests as possible and always at the lowest test levels.