Impact Analysis is some kind of research with the help of which you can indicate the most frequently affected places on the project when creating new functionality or editing the current one, and also understand how significantly they were affected.

Such parts require a large focus while performing regression testing.

When Does Impact Analysis Become Relevant?

This analysis will be the most helpful in the following situations:

1. When there are some changes in requirements on the project;
2. There is a request to make some changes in software;
3. When there should be the implementation of a new module or functionality into existing software;
4. Always, when there are changes in current modules or software functionality.

In today’s realities of IT communities, the software is becoming more complex and larger, and of course, its components are connected somehow. Changing one line of code can damage absolutely everything.

Why Is It Necessary to Perform Impact Analysis?

Information about the correlation between changes can help a tester:

• Focus on checking the functionality that was changed;
• Not to test those parts of the project that weren’t changed;
• Pay attention to those parts of software functionality that were changed and probably require some hot fixes.

How to Do Impact Analysis Correctly (Illustrative Example)?

1. Studying issue / bug / change request / ticket;
2. Familiarization with the conversation between the client and the management department;
3. Dialogue with the development department;
4. Familiarization with the part of the functionality where the change was made;
5. Analysis of the changes made;
6. Analysis of changes within the program code.

Let’s analyze each item separately.

Studying Issue / Bug / Change Request / Ticket

The most important thing that needs to be done in the first place is to study the history of how the defect was recorded and fixed in the bug tracking system. Be careful when studying the following fields:

1. Steps to reproduce;
2. Description;
3. Additional information;
4. Attached files.

Some important conditions or peculiarities that the issue can contain, may help QA to identify the sphere of future testing.

Familiarization With the Conversation Between the Client and the Management Department

Sometimes a lot of interesting things can be found in the personal chat of the client and the management department:

• Lots of clarifications and instructions from users;
• Results of research from others who participated in the process of creating and testing software;
• List of similar problems;
• Documents and other files.

The complexity of this point is that such a conversation can contain a minimum of technical terms, and for the most part – slang.

Dialogue With the Development Department

When testing changes, the basic goal of the QA company is to find as many bugs as possible. This means that the dialogue with the developers should be based on mutually beneficial principles. You can ask where exactly the changes were and what you need to pay more attention to. A good developer understands that the earlier a defect is found, the cheaper it will be to fix it.

Familiarization With the Part of the Functionality Where the Change Was Made

Changes that have been made must be stored somewhere. Such a “place” can be a specific document, method, function, or a particular module of functionality. So, it needs to be rechecked for possible regression.

Analysis of the Changes Made

In order for QA to correctly interpret the descriptions of the bugs, you first need to ensure that the developers create competent and correct descriptions of all changes.

Analysis of Changes Within the Program Code

This item is simple and clear. A tester must be able to “read” the program code and understand what exactly he/she is responsible for. Naturally, not all QA can fully cope with this, but there is a specific way you need to strive to. The tester needs basic knowledge of programming and some of the simplest OOP concepts.

Thus, a properly performed impact analysis can significantly reduce the time required for testing. After all, if you know where exactly the changes were made in the web product, you do not have to spend a lot of time re-checking the entire product.