Using the Dynamic Regression Model (DRM) in Software Development

Hi there!

Working in various companies on different projects, most of which were product development, I have acquired over seven years of experience in Quality Assurance (QA). And in that time, one recurring challenge I often face is regression testing. Before releasing a new product version, the QA team needs to ensure that the new code does not affect the existing functionality. As a result, with each release, we need to check almost the same functionality, with the addition of new test cases after implementing new features. Over time, the number of regression test cases increases, leading to longer testing periods.

Automating all regression test cases is an excellent approach, but it requires both time and a team of automated QA engineers. Another effective way to speed up regression testing is through the dynamic regression model (DRM). However, it's essential to be aware that the more legacy a project is, the more challenging it might be to implement DRM successfully. So let's talk about it!

Requirements for Implementing the Dynamic Regression Model

1. Know all feature dependencies in a code - it's not a joke but don't worry, I’ll cover how to manage it;

2. Actual regression test plan: all cases in the project should be up-to-date;

3. Feature dependency matrix.

Now let's describe each of these points in more detail:

1. Know all feature dependencies in a code

Only some developers can answer how the feature code will affect the overall application code. Will there be any regression bugs? Need time for research. And this is the first key to the successful implementation of DRM.

At my company, we assign a developer to each release, responsible for researching the impact of new code on the old codebase. So a developer spends several hours to understand what's the effect. Simultaneously, the QA engineer, responsible for the release, prepares a list of the application's functionality, which is updated with each release.

For example:

• Sign In

• Sign up

• Feature 1

• Feature 2

• etc...

That list should be updated by QA before every release.

Sometimes it could be useful to improve that list by adding a subitems list:

• Sign In
  • Login field
  • Password field
• Sign Up
  • Email field
  • Phone field
  • Name field
• etc...

When a developer finishes investigating the impact, the list should be marked where potential regression bugs could be found:

• Sign in ✅
• Sign up
  • Email field ✅
  • Phone field ✅
  • Name field
• Feature 1 ✅
• Feature 2
• etc...

QA needs to check only marked functionality. Spending several hours on careful research will save some time for making regressing test cases. I can see three good points:

• Developers take more responsibility for the released code;
• Developers better understand the codebase of the entire product;
• Reduce regression time.

2. Actual regression test plan

Keeping test cases up to date is crucial for efficient regression testing. Failure to do so can extend the regression process, as QA needs time to understand whether the problem lies in the test case, the code, or the documentation.

To prevent that problem, I implemented a "sanitary day" practice. At the end of the sprint, QA in a team spends several hours (it depends on the number of test cases) checking and updating cases. So this is the second key to the successful implementation of DRM.

3. Feature dependency matrix

Feature dependency matrix is the last but not the least. In software development, a Feature Dependency Matrix, also known as a Dependency Matrix or Feature Interaction Matrix, is a visual representation of the dependencies between various features or components in a software system. It helps to identify and understand how different parts of the software rely on or interact with one another.

Typically, the matrix lists features or components along the rows and columns. Each cell indicates the relationship between the corresponding features on the row and column. The dependencies can be represented in various ways, such as binary values: 1 for a dependency, 0 for no dependency.

The Feature Dependency Matrix serves several purposes, including:

• Dependency Visualization: It provides a clear visual representation of how features in the software depend on each other. This visualization helps developers/QA/Architects/Managers quickly grasp the interconnections and complexity of the software.

• Impact Analysis: The matrix helps perform impact analysis, which is essential when making changes or updates to the software. By understanding the dependencies, developers can assess the potential ripple effects of modifying or removing a particular feature.

• Software Architecture Understanding: It aids in understanding the software system's architecture. Recognizing feature dependencies can reveal patterns or structures that may not be immediately evident from looking at the code alone.

• Quality Assurance: The matrix can be used in testing scenarios to ensure adequate coverage of dependent features when testing individual components or integrating different software parts.

• Modularity: Analyzing the feature dependencies can lead to insights on improving modularity and reducing tight coupling between components, which are essential aspects of maintainable and scalable software.

Creating a Feature Dependency Matrix involves studying the codebase, and documentation, and engaging in discussions with the development team to accurately identify the dependencies.

Overall, the Feature Dependency Matrix is a valuable tool for software developers/QA and architects to understand and manage the relationships between features, leading to more effective software development and maintenance processes. This was the third key to successful DRM implementation.

Let's move on to specific numbers using the example of releases in my company

On average, the regression time was reduced by 55% based on 15 regressions. The overall quality remained approximately the same.

However, it's important to note that there was one release when the developer merged one branch incorrectly, and because of this did not mark the features that need to be regressed and we missed one non-critical bug on the production.

Remember, the main part of successful dynamic regression testing lies in collaboration, communication, and continuous improvement within the development team. By working together, you can ensure that every new product version is a step forward without compromising the integrity of the existing functionalities. Happy and productive testing!