This is part 1 of a 2-part series. The 1st part will discuss the culture and mindset around Agile, and how Agile Quadrants are used. Part 2 will discuss how to use the Agile Quadrant, the significance of Automation in Agile Quadrants and how to use Agile Quadrants to overcome Quality Assurance headaches.
Organizations aspire to deliver high-quality software at an accelerated rate that offers customer satisfaction and a competitive edge. Agile software development offers these attractive benefits to organizations, and this has led to its worldwide adoption. Despite its many inherent benefits, Agile transformation is still in primitive stages in most of the organizations who say they’re “doing Agile.” Adopting Agile “methodology” is effortless, but succeeding with it is challenging. Simply introducing a new Agile framework will not reap all the benefits of Agile adoption.
Developing the Mindset is Key
The biggest barrier to Agile adoption and transformation is the lack of functional responsibilities within an organization. For example, some Developers with a traditional mindset feel that testing is the sole responsibility of the Testers. They always have excuses for not testing their code. They feel that writing unit tests takes a lot of effort and wastes time. So, they would rather spend time producing new code. They bypass unit testing and favor creating new features. And for those organizations that have been successful in creating strict expectations for Developer based testing; much is still lost or forgotten when it comes to responsibilities for system integration, user acceptance, and end-to-end testing.
Bringing the shift in mindset and culture takes time and training.
Lack of understanding of Agile values and principles makes it even more challenging for the Agile teams to succeed with testing and Automation. Below are some of the questions that Agile teams face when it comes to adopting Agile:
- How to accelerate releases without compromising on quality?
- Where does testing and Test Automation fit in the development lifecycle?
- Who is responsible for quality?
- What should be our testing strategy?
- How to increase our Test Automation coverage?
- What kinds of testing should we perform?
- What tests should be automated?
In this article, we will deep dive into Agile testing quadrants and answer these questions in order to help you to overcome Agile testing and Automation challenges.
What is Agile?
Agile is NOT a methodology or a set of rules, guidelines, and practices. Agile is a mindset guided by the values in the Agile Manifesto and the 12 principles behind it. Unlike traditional development methodologies, Agile values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile development methods are iterative, incremental, and adaptive. Agile aims to satisfy the end-users early and Continuous Delivery of valuable software. Agile teams embrace changes, even in late development stages, to provide their customers with a competitive edge.
Organizations that are transitioning to Agile struggle to understand how testing is integrated at every step in the development lifecycle and oftentimes the old, monolithic QA organization is abruptly disbanded or quickly re-organized to ensure the successful transition to an Agile based organization leaving very little hand-off of processes, people and tools to effectively deploy QA in Agile. As a result of the transition, QA Managers and QA Directors are often re-purposed within the organization to other job duties rendering them powerless to influence a QA blueprint within the constructs of Agile.
As a response to this, the Agile communities have come to embrace testing quadrants to help ensure governance and enablement for QA practices across the teams and iterations. It assists Project Owners, Scrum Masters, and Value Stream Leaders to create an effective strategy to resolve QA needs at scale across teams, squads, and tribes.
Agile Testing Quadrants
Brian Marick (XP proponent and Co-Author of Agile Manifesto) classified software tests in the form of an Agile testing matrix. This taxonomy placed tests in 2 dimensions:
- Support programmers or critique the product
- Business or technology facing.
This approach was further developed by Lisa Crispin and Janet Gregory in their book Agile Testing.
The quadrants numbering has nothing to do with how the tests should be sequenced or prioritized. It’s an arbitrary numbering used to simplify describing the tests and their goals.
Below are the 4 quadrants and what they represent:
The tests on the left side of the quadrant focus on preventing defects, and the right side focuses on finding defects and discovering missing features. The tests on the top half are business-facing, and the bottom half is technology facing.
Q1 – Technology-facing tests that support the team
Quadrant 1 (Q1) comprises unit tests and component tests. These tests are usually automated and provide early and quick feedback. In Agile development, quality is a shared responsibility. One of the ways Developers contribute to quality is by writing automated unit/component tests. Unit/component tests support the team to build and change the application rapidly with confidence. Q1 focuses on internal code quality and is primarily the home of test-driven development (TDD).
Q2 – Business-facing tests that support the team
Quadrant 2 (Q2) comprises functional testing, story tests, prototypes & simulations, examples, etc. Most of the projects start in this quadrant. This quadrant focuses on business requirements and turning them into tests from the perspective of a business person. Q2 requires both manual and automated tests to be effective and often software that is highly interdependent systems integration testing could begin. Q2 focuses on eliciting the requirements and is primarily the home of Behavior Driven Development (BDD).
Q3 – Business-facing tests that critique the product
Quadrant 3 (Q3) comprises Exploratory Testing, scenarios, usability testing (UAT), Alpha/Beta testing, heavy system integration testing, etc. Q3 focuses on providing feedback to Q1 and Q2. These tests are now often automated and rely on simple to use no-code/low-code tools to enable non-technical teams to provide key user insight and defect reporting with repetition.
Q4 – Technology-facing tests that critique the product
Quadrant 4 (Q4) comprises Performance/Load Testing, Security Testing, and other non-functional tests. Tests in Q4 ensure that the application under test meets the non-functional requirements. Q4 is majorly tool-driven,often automated, and most importantly, usually cross-functional.
There are no hard and fast rules about which tests belong in which quadrant but rather agile leaders who own the responsibilities for managing Q3/Q4 and/or systems teams as found in SAFe (Scaled Agile Framework), to ensure this function is properly resourced, trained and enabled to support ongoing iterative process of quality infusion within each release.
Summary
This concludes part 1 of Using Agile Testing Quadrants to solve Quality Assurance headaches. As companies continue to transform themselves into highly Agile development organizations, it’s imperative that a shift in mindset is key in terms of knowing there will be fallout of quality assurance responsibilities unless careful considerations are taken in advance. Taking time to train, and educate your staff on Agile values and principles, and organizational structure will help with a successful implementation. Agile Testing Quadrants are a resource to help ensure effective coverage of risk improvement and QA governance across various project and cross functional teams. Part 2 will discuss how to use the importances of Agile Testing Quadrant, the pitfalls of disconnected teams, and solutions you can use to ensure reducing risk, increasing coverage, and overcoming headaches brought on by Agile transformations.
