Software change impact analysis

For developers, QA leads and SRE teams reviewing an unfamiliar change. Use dependency information to prioritize review and testing, while keeping unknown relationships visible.

What Zof does

• What a change can affect

  The System Graph resolves affected systems, criticality, applicable controls and incident history for a change, so review and testing start from what the change can reach.

• A review starting point

  Impact analysis identifies changed files, affected areas, candidate tests and dependency paths. It does not establish that every affected service or customer has been found.

• System Graph evaluation

  Review how repository dependencies connect to your services, APIs, owners and release workflow. Confirm the available data sources and coverage on one system.

From a change to a review decision

1. 01

   Define the comparison

   Supply explicit changed paths or supported Git revisions. Check that the selected repository, base and head match the change under review.

2. 02

   Review dependency paths

   Inspect affected areas and candidate tests. Read unresolved relationships and completeness warnings before deciding which additional areas need investigation.

3. 03

   Run and retain checks

   Run the relevant trusted tests in your existing runner. Keep the impact report with actual test results and the review decision. A suggested test has not yet run.

What evidence you get

• A traceable path

  Each affected area should trace back to the dependency path that connects it to the change, so a reviewer can check why it was included.

• Candidate tests

  Candidate tests help focus review. They are tests associated through the dependency graph, not measured coverage or a guarantee that other tests are safe to skip.

• Coverage boundaries

  Results should state their limitations and whether the graph is complete. Even a complete graph is complete only within the relationships it models.

Prerequisites and limits

• Revision comparison requires Git history and accessible base and head revisions.
• Computed dynamic imports, path aliases, custom loaders, runtime dependency injection and network calls may be unresolved or absent from a static view.
• Configuration changes and relationships outside the repository require wider review.
• Import reachability is not proof of runtime behavior. Review unresolved edges and preserve broader regression checks when risk warrants them.
• Cross-service topology, ownership and production history depend on the data sources connected in your deployment. Validate them on one system before relying on them.