Agile Testing Quadrants to Continuous Delivery and DevOps Culture
Documentation and testing are two exercises that have traditionally been given quick shrift on software development teams. Documentation in the form of text or illustrations helps the underappreciated part of describing how a program works or how to use it. Unfortunately, many developers have discovered the hard way that complete documentation is wasteful and often can’t be trusted because it’s normally out of sync with the code it’s intended to describe particularly on dynamic projects with changing requirements.
Testing is underrated on traditional software teams, too, particularly among developers who think the tester’s job is to break the code that they’ve given hours crafting. While one of the wide guidelines of the Agile Manifesto is to appreciate working software over comprehensive documentation, since “working software is the principal measure of progress” on Agile projects, the value of testing on agile DevOps projects has, if anything, grew in value.
Agile development practices a test-first strategy rather than the test-at-the-end way of traditional development. In Agile testing, code is produced and tested in small additions of functionality. Nearly all DevOps environments adopt Agile project management and product development methodology that encourages frequent interaction among IT departments and business users and seeks to constantly build and deliver software that matches users’ changing conditions. This suggests, in effect, generating a continuous, two-way DevOps software pipeline among you and your customers.
Developing a successful Continuous Delivery pipeline means building a DevOps culture of collaboration between the various teams included in software delivery (developers, operations, quality assurance, business analysts, administrators, etc.), as well as reducing the cost, time, and risk of producing software changes by providing for more incremental updates to applications in production. In practice, this indicates teams produce software in short cycles, assuring that the software can be probably released at any time.
Agile development acknowledges that testing is not a separate phase from coding, but an essential part of the software development process. Because Agile is an iterative development methodology, testing and coding are done incrementally and interactively. Features can develop in response to evolving customer requirements. Agile testing covers all kinds of testing, i.e., unit, functional, load, and performance tests. The following Agile Testing Quadrants diagram is a valuable tool for cross-functional Agile development teams to use to design and execute testing activities.
Applying the quadrants to plan testing in DevOps
Teams choosing a DevOps mindset operating towards continuous delivery, configure deployment pipelines that involve many testing platforms– both human-centric and automated. They exercise release feature toggles or feature flags to cover differences in production while they complete testing. They release when they feel positive, and they constantly watch production to look for exceptions and errors.
This continuous delivery world has started to make sense for many of us, yet we observe many teams scraping their collective heads. “It was difficult to implement testing activities into two-week release cycles. How the heck do we prepare complete testing done when we release twice a week, multiple times per day?” This is where the agile testing quadrants can ease the transformation.
The quadrants are a thinking tool. Your team can utilize them to build a common language to make conversations easier. It helps with planning at every level. Notice that we haven’t said anything about “only” testers practicing the quadrants. It is a tool that allows the whole team to take charge of planning and performing testing activities.
The four quadrants are explained in more detail below.
These are technology-facing tests that manage development, such as unit tests, API tests, web services testing, and component tests that enhance product design. Tests in Q1 are often linked with automated testing and Continuous Integration.
These are business-facing tests that manage development (i.e., those used for functional testing, story tests, prototypes, and simulations) that ensure your software products are correctly aligned with the business. Tests in Q3 are often connected with both automated and manual testing.
Business-facing tests used to assess or critique the product. Q3 incorporates tests such as exploratory testing, user acceptance testing, usability testing, scenario-based testing, and alpha/beta testing. It can include product demos intended to get feedback from actual users. Tests in Q3 are often linked with manual testing.
Technology-facing tests used to assess or critique the product. Q4 incorporates tests that have to do with performance, load, stress, maintainability, memory management, scalability tests, recovery, safety, compatibility and interoperability, data migration, and infrastructure. These tests are usually automated.
The clouds at the quadrant corners imply whether tests in that quadrant usually need automation, manual testing, or specialized tools. The distribution of tests into quadrants permits teams to strategize whether they have the relevant skills to achieve each of the different types of testing, or if they have the required hardware, software, data, and test environments. It also makes it easier to customize your agile testing method on a project-by-project or skill-by-skill basis.
For example, if you don’t have a tester on your QA team with suitable load or performance testing skills, it benefits you see the requirement to bring in a contractor or outsource that particular test. A testing strategy based on the Agile Testing Quadrants needs effective workgroup communication, which is done easier by a test management tool that enables the team to work collaboratively in real-time.
These are just a few examples of TestUnity Experts use the quadrants to plan testing activities successfully adopt continuous delivery. Connect with TestUnity experts so you don’t have to slow deployment down on DevOps projects committed to delivering software rapidly, frequently, and more reliably.