Using Agile Testing Quadrants to Solve Quality Assurance Headaches: Part 1 of 2

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:

  1. Support programmers or critique the product
  2. 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.

Clayton Simmons
Clayton Simmons has 10+ years in Enterprise Services Business. Clayton ran Cognizant’s Digital Assurance Practice in 2012 and lead an organization focused solely on testing digital enterprise digital solutions for both Mobile and IoT. He successfully rolled out Customer Experience (CX) Test offering which revolutionized the approach to the perceived quality quotient against traditional functional validation of so many other testing services at that time.

The Related Post

LogiGear Magazine July 2012 Testing in Agile  
Keeping an eye on the horizon in the testing world is an important part of staying in the game. Hans is no stranger to looking to the future with eyes wide and ears open. His expertise is what makes Hans valuable at the STARWEST Expo, which he recently delivered two talks to.
Video narrated by MICHAEL HACKETT – Certified ScrumMaster This is Part One of a Four Part Video on “New Roles for Traditional Testers in Agile Development” Michael shares his thoughts on “A Primer – New Roles for Traditional Testers in Agile” LogiGear Corporation LogiGear Corporation LogiGear Corporation provides global solutions for software testing, and offers ...
Testing in Agile Part 1 – INTRODUCTION TO AGILE In case you missed the first part of the series in our last magazine issue from Michael Hackett, Agile’s impact on software development teams is huge. For test teams it can be even more pronounced — and good, especially if your existing projects have been problematic.
Writing code that is easy to read and easy to test is difficult to achieve. The fact that poorly written code can function often leads to coding practices that are effective but not necessarily efficient. Too often, many programmers fresh out of school write code in the manner that was effective for passing their courses, but contains ...
Video narrated by MICHAEL HACKETT – Certified ScrumMaster This is Part Three of a Four Part Video on “New Roles for Traditional Testers in Agile Development” Michael shares his thoughts on “A Primer – New Roles for Traditional Testers in Agile”   LogiGear Corporation  LogiGear Corporation LogiGear Corporation provides global solutions for software testing, and ...
“Agile is to software development what poetry is to literature. It is very difficult to do well, very easy to do poorly, and most people don’t understand why a good poem is good and a bad poem isn’t…” – from the web
LogiGear Magazine – November 2010
Maximize the function of your teams The Modern Agile philosophy created by the folks at Industrial Logic is one of the most exciting ideas I’ve encountered in a while. Moving beyond the pre-canned “You must do X to be Agile” mindset that I’ve seen becoming more and more prevalent.
Author of The Agile Warrior, Rasmusson answers questions from LogiGear’s testing staff about test automation in agile projects.
Janet Gregory draws from her own experience in helping agile teams address alternative ways to cope with roadblocks including projects without clear documentation, testers with limited domain knowledge and dealing with either black box or white box testing. For testing on projects without clear documentation, is exploratory the only method? I often make “tester errors” ...
Agile is here to stay. Once the radical alternative to Waterfall development methods, these legacy methodologies are being disrupted and replaced by Agile practices that improve time-to-market, reduce development costs, and produce higher quality software that better meets customer expectations. As the world demands more software, development teams – from scrappy startups to big corporations ...

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay in the loop with the lastest
software testing news

Subscribe