Recall the concepts of test pyramid & testing quadrants and assessing the quality risk in agile projects

Vlad

April 12, 2021
7 min read
Agile Approaches Agile Testing Assessing risk SCRUM Test Pyramid Testing Quadrants

The agile approach is often the chosen method one team is following in order to complete a project. Regardless of the chosen framework like XP, SCRUM or Kanban the organizations will need to accommodate their work to correctly implement all the practices and instruments that come with those frameworks. Teams can implement various techniques and practices to produce quality results.

Starting from writing tests in advance to develop the software, focus on requirement analysis in an early risk analysis meeting, detecting and fixing bugs first to remove any potential negative effect on the product under development, or making sure that the right development and testing approaches take place and the right test types are executed as part of the main test levels.

Even though these can be complex to achieve and understand at the beginning, agile teams are often focused on putting all of these actions at the beginning of the project. Testers in particular are playing a big role in guiding all those actions throughout the project lifecycle.

Some of the testing techniques that I mentioned in previous blog posts are TDD & BDD. Approaches that the team can follow to develop, test, and release the software to its customers and sure the released product introduces no or minimal minor issues. The other approach that I will explain in this post is called Acceptance Test-Driven Development or in short, ATDD.

What is ATDD?

ATDD focuses on the acceptance criteria and coverage of the tests while the user story is being created. Every team member plays a role in this approach since the benefit from this would be that the end-user or the stakeholder understands what is the product about, how to use it, and what are the test flows that a user would take once released to production.

One of the main benefits of this approach is having tests prior to implementing the user story that can be part of the regression test suite and integrated as part of the continuous integration process. These tests can be positive (confirming that the scenarios are working fine as part of the happy flows) and negative (edge-cases or invalid inputs to see how the system would respond) as well as any non-functional testing activities like usability, accessibility, visual testing, or performance. This allows detecting defects early and validations that the system is working as it should from A to Z.

Test Pyramid

Now, we understand that the software is tested at some point of the development lifecycle right? No software should be shipped without testing it first. And to ensure that it satisfies all the requirements requested by the customer the team needs to introduce testing at different levels of the system.

Test Pyramid is an approach that ensures that the team is having the largest number of tests at the lower levels of the system, testing the units one by one and validating the interaction between them. On the upper levels, the number of tests is decreasing since the tests would be pretty big and would take a longer time to execute compared to those on the lower levels.

In other words, the test pyramid ensures that we have a large number of API automated tests on the unit and integration level and have a small number of GUI automated tests at the system and acceptance level. As a result, we would test the system early, detect bugs early and eliminate them in time.

Explaining the Testing Quadrants

The goal of setting testing quadrants is aligning the test levels with the specific test type. It makes sure that all of the testing types are included in the project lifecycle.

There are 4 testing quadrants. The tests inside the quadrants can be business or technology-focused. They can validate the system behavior or they can critique the product in terms of how it is developed.

Quadrant 1

The tests in the first quadrant are unit-level tests, technology-focused, often automated, and part of the CI process.

Quadrant 2

The tests in the second quadrant are system-level tests, business-focused, and validate the system behavior. Examples can be functional tests, user story tests, test examples, etc. These types of tests check the acceptance criteria and they are created during the development of the user story. They can be manual or automated and can be part of the regression test suite.

Quadrant 3

The tests in the third quadrant are UAT-level tests, business-focused, and they criticise the product. Types of tests can be exploratory testing, alpha & beta testing, user acceptance testing, etc. These tests are manual tests since their goal is to verify the system satisfies the user’s expectations.

Quadrant 4

The tests in the fourth quadrant are technology-facing or operational system tests. Are often critic the product using non-functional testing activities. Examples of Q4 tests are performance, load, usability, stress, compatibility, maintainability interoperability, etc. The tests are automated and can be part of a separate non-functional regression suite.

All these test types can be required during a sprint since those are dynamic tests which is focus on the quadrants rather than executing static testing.

Interested to learn more about how to measure the performance of your project? Check out this amazing course: Performance Testing Using JMeter By Edureka which covers broad topics about website performance and performance testing.

Assessing the risk in agile projects

Before we discuss assessing the risk, we must understand what is a risk in the beginning. Risk is a potentially negative outcome of an action or an event. Every risk has its level which is defined by the likelihood of the risk happening and its impact on the system. There are two types of risk, product and project risks, and these are initially discussed in the release and sprint planning where high-level risk analysis is provided and assessed accordingly by all the members of the team.

Early risk analysis meetings can reduce the chances of introducing issues of different nature. The QA’s act as facilitators of that meeting which is held in a professional environment. The main steps in the risk analysis meeting where the testers are facilitators can be:

All the members of the team are gathered
All the items from the sprint backlog are listed
For each item, the risk is identified
Each risk is assessed
Estimate the test effort affected by the risk
Define and establish the test strategies for reducing these risk

The QA’s then create the tests that can be of functional and non-functional nature. Any potential change to the system can affect the risk identified. Adjustments can be done after a change which include:

Risk identification
Assessing the existing risks
Risk strategy re-evaluation

Test estimation

When a user story is written, the product owner explains the story to the estimators. The estimators are all the team members (developers, business analysts, testers). Each member has cards that represent the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, 34, …). Each card value acts as a story point or effort days needed to finish the story. After a thorough discussion, every team member raises a card to give his estimation.

If all the members have the same number raised, then that number is given to the story as an estimation which results in how many days or how much effort would be needed by the team to completely develop and test the story. If the number is not the same, another round of discussions occurs until an agreement is reached either by consensus or by applying rules like using the median or the highest estimate. This type of estimation is called a planning poker session.

By following this approach to estimation, the team can gather the most knowledge of all the items in the backlog, and also, it would give them the confidence they need to progress towards the completion of the project.

Share This Post

Latest Posts