Impact Analysis in Software Testing

What is Impact Analysis?

Impact Analysis is the process of analysing the impact of changes made to a deployed product or application. It identifies the areas of the system that may be affected when a particular section or feature of the application is changed.

The impact is assessed across Requirements, Design & Architecture, Test, and the delivery Schedule.

Whenever new features are added to an application or product, it is imperative to check how those changes will influence the performance and stability of the system. Impact Analysis is done for this reason.

Why is Change Impact Analysis Done?

• To understand the possible outcome of implementing the change. Adding too much functionality to a product can reduce the overall performance.
• To identify every file, document, and model that might need to be modified if the team decides to implement the change.
• To estimate the effort required to implement the change.
• To identify the tasks required to implement the change.
• To list the dependencies on the specific element being changed.

What is an Impact Analysis Document?

An Impact Analysis document can be used as a checklist to evaluate a change request before the team starts working on it. The document should capture details such as:

• A brief description of the issue.
• An explanation or example of how the defect causes failure or inefficiency.
• An estimate of complexity.
• An estimate of cost and time for the fix.
• The functionality to be tested.
• The new test cases created for the change.
• Reference documents such as the technical specification or related design notes.

Example:

Impact Analysis Document.

1. Change Request ID:
2. Title:
3. Description:
4. Date Prepared:
5. Prioritisation estimate:
   • Relative Benefit
   • Relative Penalty
   • Relative Cost
   • Relative Risk
6. Estimated total effort: ______ hours
7. Estimated lost effort: ______ hours
8. Estimated schedule impact: ______ days
9. Quality impacted:
10. Other requirements affected:
11. Other tasks affected:
12. Integration issues:

How to Present the Impact Analysis Influence Level

Impact Analysis can be represented with a colour code that shows the criticality of the changes on the system. A common colour code is shown below:

• Red — Strong impact
• Yellow — Moderate impact
• Green — Weak impact

The table above explains the impact of the implemented changes:

• Features marked in red are the main features that are changed. Features in yellow are less influenced by the change. Features in green are influenced the least.
• Features listed vertically are those that are being changed. Features listed horizontally are those that the change can influence. In the example above, a change in Feature 1 influences Feature 3.
• On a larger project where features and functionalities are numerous, the table above may not be practical. In that case, another approach is adopted where the developer directly marks the level of influence caused by the changes in the main features, as shown below, where the impact of the main feature is marked against each sub-feature.

Sample questions to address while performing Impact Analysis:

• What are the adverse side effects or risks of making the proposed change?
• Does any new tool need to be acquired to implement and test the change?
• If the change is accepted, how much of the effort already invested will be lost?
• Do the proposed changes adversely affect performance requirements?
• Is additional user input required to verify the proposed change?
• Does the change increase the product cost?
• Does the current staff have the knowledge and skills to deliver the proposed change?
• Does the proposed change place any unacceptable demand on any computer resource?

Best Practices for Change Impact Analysis

• Before starting Impact Analysis, make sure the testing request identifies every part of the project that is influenced by the changes.
• Continuous communication between developer and tester is a must so that no change required in the final product is missed.
• Identify whether any user interface changes, deletions, or additions are required.
• Estimate the number of acceptance, system, and integration test cases that will be required.
• Identify any impact of the proposed change on the project plan, configuration management plan, or quality assurance plan.

Types of Impact Analysis in Software Testing

Change Impact Analysis is not a single technique. Practitioners typically use one of three complementary types to answer different questions about a proposed change.

• Traceability Impact Analysis: Uses the Requirements Traceability Matrix and design linkages to map every requirement to the modules, tests, and documents that implement it. When a requirement changes, the matrix reveals every downstream artefact that must be updated or re-tested.
• Dependency Impact Analysis: Studies the call graphs, data flows, and interface contracts inside the codebase. A change to one module is traced through direct callers, indirect callers, and shared data structures so hidden ripple effects are surfaced before the change ships.
• Experimental (Historical) Impact Analysis: Looks at historical change data — past defects, failed sprints, and regression escapes — to predict how the current change will behave. Modern tools combine mining of version-control history with statistical or machine-learning models to score the risk of each change.

Most teams combine at least two of these types. Traceability tells you what documents are affected, dependency analysis tells you what code is affected, and historical analysis tells you how risky the change is likely to be.

Popular Tools for Change Impact Analysis

Modern Change Impact Analysis is rarely done in a spreadsheet. Teams pair a requirements management tool with a code-analysis tool and a test-management tool that share a common traceability spine.

• Jama Connect, IBM DOORS, Modern Requirements, and Visure Requirements: Capture requirements, maintain baselines, and generate impact reports across linked requirements, tests, and risks when a change is proposed.
• Atlassian Jira with Xray or Zephyr: Track user stories, defects, and test cases. Impact reports show every story and test that a proposed change touches inside a sprint or release train.
• SonarQube, Understand by SciTools, and Structure101: Analyse source code dependencies and produce call graphs and coupling reports so the engineer can see downstream code affected by a change.
• Launchable, Testim Auto-Heal, and TestGrid: Use machine learning to predict which tests are most likely to catch defects introduced by a change, enabling smart test selection and faster regression cycles.
• Microsoft Excel or Google Sheets: Still widely used for the initial Impact Analysis document, colour-coded influence table, and change request log on smaller projects.

The right combination depends on the size of the codebase, the regulatory environment, and the delivery method. Regulated industries lean on Jama or DOORS for auditable traceability, while agile product teams rely on Jira, SonarQube, and a test-impact tool.

FAQs