Impact Analysis 

Impact Analysis is a study that allows you to specify the affected areas (affected areas) in the project when developing new or changing old functionality, as well as determine how significantly they were affected. 

Affected areas require more attention during regression testing.

When Should I Conduct an Impact Analysis? 

Impact analysis can be useful in the following cases: 

1. there are changes in the requirements; 
2. received a request to make changes to the product; 
3. the introduction of a new module or functionality into an existing product is expected; 
4. whenever there are changes to existing modules or functionality of the product. 

As we know, nowadays products are getting bigger and more complex, and components are increasingly dependent on each other. Changing a line of code in such a project can “break” absolutely everything.

Why do you need to conduct Impact Analysis? 

Information about the relationship and mutual influence of changes can help QA:  

1. focus on testing functionality where changes have been introduced;  
2. take into account the parts of the project that have been affected by the changes and may have been affected;  
3. do not waste time testing those parts of the project that were not affected by the changes.

How to conduct Impact Analysis? 

1. Examine the issue\ticket\bug\change request. 
2. Read email correspondence. 
3. Conversation with developers. 
4. Examining the location where the change was made.
5. Study description of changes. 
6. Watch for changes in the code. 

As you can see, only “step 6” requires the ability to read code, “steps 1-5” can be handled by QA even without knowledge of a programming language.

1. Examine the issue\ticket\bug\change request. 

The most basic and basic thing to do is to carefully study the issue in the bug tracking system. Pay attention to all fields, especially: 

• Steps To Repeat; 
• Description; 
• Additional background information; 
• Attachment; 

Some important conditions or features described in the issue will help you identify the area of ​​testing. For example, when you carefully read the issue, you find that the ‘Additional Background Information’ is marked that the problem can only be reproduced when using HTTPs. Therefore, we can note that when testing it would be nice to check the case with HTTP.

2. Read emails 

You will be surprised how much can be found in correspondence related to your task that was omitted and not indicated in the issue: 

• more details from customers; 
• research results from other team members; 
• list of similar problems; 
• pictures, graphs, diagrams, and more.

3. Conversation with developers

When testing changes, your goal is to find as many “broken” as possible and therefore you should boldly approach the developers, those “who may have broken” and ask directly: “You made changes, tell me what they can affect, what areas/modules I need to check more carefully.” A good developer who understands that the sooner a bug is discovered, the cheaper it will be to fix it, will help you with advice, even if he is absolutely sure of his changes.

4. Examining the location where the change was made.

Changes that are made must be made somewhere. An example would be git, where it’s fairly easy to determine where the changes were made. By “place” I mean “specific file, specific function/method, specific module”. And therefore, this “place” (this module, functionality) should be rechecked, tested for regressions.

Also, if they have been changed in some client files (JS, HTML, CSS, etc.), cross-browser testing should be carried out.

5. Study description of changes. 

In order for QA to study descriptions, you first need to ensure that Developers start writing competent and understandable descriptions of changes. It would be nice if the developers followed the pattern for describing changes (git commits):

Ticket number and title 

• Bug: {What is the defect, what is the actual behavior of the system?} 
• Problem: {root cause of the defect, what is wrong with the system?} 
• Fix: {what is the change}

6. Watch for changes in the code

Everything is simple here – you need to read the code and imagine what it does. Of course, not many people can do it at this stage, but there is something to strive for. In addition, a deep understanding of the code is not always required. Basic knowledge of programming and a smattering of OOP knowledge may be enough to present a use case that covers the main functions.