The first quadrant (Q1) is associated with automated testing and covers test types like unit tests, component tests, and API testing. This quadrant is important 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 gain a deeper understanding of 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, but in order to maximize their efficiency, the team should use TDD as a development approach, as it forces programmers to really understand the behavior of their code as they write the tests that will approve it.
By 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, there is a customer waiting for the product at the end of each sprint who will not allow the team to invest endless time on 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 1 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 that makes 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 at 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, but in my experience, you can stop these tests only when you have the confidence that the code has good coverage that guarantees that there are no critical issues at the advanced phases of development. I use a simple rule stating that you should automate as many tests as you can, and always at the lowest test levels.