By Guest Blog | December 3, 2017
A good agile product development manager knows that you can’t separate coding from testing.
Because agile methodologies are iterative, testing and coding are done incrementally and interactively so that features can evolve in response to changing customer requirements.
Agile testing comes in many shapes and sizes and covers all types of testing, including unit, functional, load, and performance tests. Depending on what type of agile testing you’d like to do: from automated, to manual, and everything in between, there are different test types you can choose from. How can you choose which type of test to perform and for what benefit?
The 4 agile testing quadrants
Agile expert Lisa Crispin developed four Agile testing quadrants as a guide for managers and development teams to use to create test strategies. It’s important to realize that the Agile Testing Quadrants diagram is simply a taxonomy to help teams plan their testing and that there are no hard and fast rules about which tests belong in which quadrant and in which order the different tests need to be done. (For example, it’s not necessary to work through the quadrants from Q1 to Q4 in a waterfall style.)
Quadrant Q1: These are technology-facing tests that guide development, such as Unit tests, API tests, Web Services testing, and Component Tests that improve product design. Tests in Q1 are often associated with automated testing and continuous integration.
Quadrant Q2: These are business-facing tests that guide development, such as those used for Functional Testing, Story Tests, Prototypes, and Simulations that make sure your software products are properly aligned with the business. Tests in Q2 are often associated with both automated and manual testing.
Quadrant Q3: Tests in quadrant 3 are business-facing tests used to evaluate or critique the product. Q3 covers tests such as exploratory testing, scenario-based testing, usability testing, user acceptance testing, and alpha/beta testing and can involve product demos designed to get feedback from actual users. Tests in Q3 are often associated with manual testing.
Quadrant Q4: These are technology-facing tests used to evaluate or critique the product. Q4 covers tests such as performance, load, stress, and scalability tests, security tests, maintainability, memory management, compatibility and interoperability, data migration, infrastructure, and recovery testing. These tests are often automated.
How to choose which test to use
Crispin’s four quadrants are based on Brian Marick’s Agile testing matrix, which makes a distinction between tests that are either business facing or technology facing. A business-facing test is one you can describe to a business expert in business terms, such as, “if your user’s account is overdrawn, will the system add a service fee?” A technology-facing test is one that uses language that developers might understand, such as, “PersistentUser#overdrawn adds service fee.”
Marick also recognizes a difference between tests that support the development team or critique the product. By tests that “support the team,” he means tests like component or unit tests where testable parts of an application are individually and independently scrutinized for proper operation. Tests that “critique the product” are those that are not focused on the development process but look at inadequacies in the finished product, such as not fulfilling a business requirement.
The division of tests into quadrants allows teams to strategize whether they have the right skills to accomplish each of the different types of testing, or if they have the necessary hardware, software, data and test environments. It also makes it easier to customize your agile testing process on a project-by-project or skill-by-skill basis. So, for example, if you don’t have a tester on your QA team with appropriate load or performance testing skills, it helps you see the need to bring in a contractor or outsource that particular test. A testing strategy based on the Agile Testing Quadrants requires effective team communication and collaboration, which a tool like JIRA can facilitate.