How often do you have to solve problems when, after conducting an audit of the software testing process, your recommendations are quite general and not useful? Or even worse, when, after the implementation of new technologies, you do not get the expected result, which calls into question your competence among managers.

Sometimes the main problem of such problems is the manager’s misunderstanding of the task set by the top management, and, as a result, the incorrect selection of the methodology for auditing/testing software by QA.

First of all, we have to analyze the basics of software testing and understand how each process should work. So, any process whether software testing or quality control should be performed circularly.

There are 4 basic approaches to working with processes but the most popular is the Deming cycle. It is the basis for process work and other methodologies, for example, EFQM, IDEAL, DMAIC. All they suggest is that we should not only claim the implementation of the process but also analyze and constantly improve it.

Regarding software testing, there are 2 fundamental approaches to improve the test process. We’re talking about MBI and ABI.

Model-Based Improvement (MBI)

This is an approach to improve the testing framework methodology. It’s based on reference models for optimizing the software verification process. This approach can consist of models, for example, TMMi, TPI, or in context (STEP, CTP). Such models make it possible to build the testing process according to certain steps. Thereby, you’ll improve the testing process evenly and consistently.

Model-Based Improvement is best to use only for solving problems of assessing the maturity of the software verification process and creating a model for the development of the testing process for long time intervals (terms). In all other situations, when you need to solve a problem related to test optimization, MBI cannot help you with that.

Analytical-Based Improvement

This is a special approach to improve the fundamentals of the verification process that is built on analytical approaches of process analysis. The main difference between the model approach and the analytical one is when testers analyze the process according to the MBI method, it goes from top to bottom. In other words, we study the entire process at first, then we divide it into parts, thereby gradually delving into the details of the process.

The analytical approach has a different structure. Namely, first of all, we immerse ourselves in the most important details of the process. And only then, we solve the main problem of the project following the plan upward.

But all this is not enough to conduct a full-fledged test audit. And here it is worth using Root Cause Analysis.

Concept of Root Cause Analysis

Root cause analysis is a special approach for finding hidden reasons which help a user to see why this or that defect occurred.
Hence, RCA is some kind of tree-like hierarchical structure of dependence of some reasons both with a bug and among themselves.

As a rule, testing problems should include only those problems which are somehow related to a standard triangle – price/time/quality. Why is it so? The answer is simple! The point is that the business of the entire company should support all the IT processes.

The IT sphere is the modern business assistant. Hence, when a business says that it’s impossible to implement all the verified features, then this isn’t a problem of the business but of the testing department.

Traditionally, the Audit Process According to the RCA Criteria Consists of Five Stages:

1. Find a problem and the basic factors of its influence on common goals,
2. Search for potential causes;
3. Finding information and analytics of potential causes;
4. Building cause-effect relations;
5. Minimization of various negative consequences for goals by finding the most effective solutions.

Let’s say we were able to find and identify an actual problem as a significant shift in the timing of software release. A clear sign of a problem, in this case, most likely will be the systematic nature of its reproduction.

There’s a difference if the time shift occurs once in 7 releases and if the seventh shift destroys the plans for a single release. The second case directly indicates that the problem is critical.

Undoubtedly, you cannot solve it all immediately. So, if any problems arise, you must first select the most significant ones as they affect the product and resolve them separately.

After you define the problem, you can start searching for possible causes of its occurrence. The easiest way is the brainstorming technique by all members of the development and testing department. One of the options is to ask all the specialists their opinion about the causes of the defect. And then you can select from this list the most frequent ones (and start the fixing process with them).

Analysis of Potential Reasons for Bug Occurrence

In actual practice, there are several analysis techniques, such as dependency diagrams, affine diagrams, and Pareto diagrams.

By the method of brainstorming, you can identify about five new causes of the problem that affect something. In our case, it is the shift in the deadline for the planned release. Now the management department and testers have to understand which reasons are most influencing the problem being analyzed. Here you can use a Pareto chart to fix the number of person-days that are lost due to the onset of a particular problem.

The next step is to describe cause-effect relations with the basic goal of capturing root causes and their dependencies. For this purpose, it is best to use a causal analysis diagram. In this case, a user delves into the root of the causes at each level while solving the problem. Thereby, he/she is looking for the basic catalysts for the occurrence of problems. As a result, having solved the root problem, a person automatically solves all other problems.

For the final implementation of the cause-effect analysis, it is necessary to display all the problems in a tree-like form that were previously discovered based on the Pareto principle. Next, we need to prioritize them and establish dependencies.

And the final stage is the development of solutions to the problem. After completing the RCA analysis, the decisions will be logically understandable. The entire project team should aim them at a specific goal and implement them in practice.

To Sum Up All the Described Above

It is worth noting the fact that if you have to optimize the software testing process, but before it you should solve the current problems with the testing process (resources, time, system environment, etc.), you need to use the ABI and MBI approaches. After all, these models make it possible to solve problems and significantly optimize testing processes and all related tasks.