Impact Analysis

3 min read

“We changed this — what has to be retested?”

It is the question every regression conversation starts with, and it needs a model of what depends on what. Atlas is the only surface in Hawzu that has one.

Run an Analysis

Select a node on the map and open its inspector.
Select the impact action — What else moves if this changes?
Read the ranked worklist in the impact panel.

You can also seed the analysis from something other than a node — see below.

What You Can Seed From

Seed	Resolves through
Node	Directly — the part of the map you changed
Requirement	The nodes linked to that requirement
Test case	The nodes it covers
Canon document	The nodes grounded in that document
Defect	Indirectly, through the entities the defect references
Release	Indirectly, through its executions

Two controls shape how far the analysis reaches:

Depth — how many hops out from the seed to walk. Start shallow. A deep walk on a well-connected map returns most of the product, which is true and useless.
Include navigation routes — off by default. Dependency routes mean changing this breaks that; navigation routes only mean a user can walk between two screens. Including them widens the blast radius considerably and is worth doing when the change is to shared UI.

Dependency Routes Are Walked in Reverse

This is worth stating plainly because it decides whether the answer is right.

“A depends on B” means changing B breaks A. So from a seed, Atlas follows routes whose target is the current node — the things that need the changed thing, not the things the changed thing needs.

If your dependency routes are drawn backwards, impact analysis returns a confident, plausible, exactly wrong answer. See Nodes and routes for how to draw them.

Reading the Results

Results are grouped into three tiers rather than scored:

Tier	Meaning
Must retest	On the changed node, or touching a critical journey
Should retest	One step out, or previously failing
Consider	Reachable, but further out

Tiers rather than a weighted score, because there is no data to calibrate weights against and a number a user cannot predict is worse than a bucket they can.

Every test case says why

No row is a bare entry. Each carries the reason it is in the list — it sits on the changed node, it belongs to a journey that crosses it, it covers a linked requirement, or it lives in a linked folder. Hovering a row lists every reason that applies.

The reason is not implied by the tier. Two tests can both land in Must retest, one for sitting on the changed node and one for touching a critical journey.

Each row also shows the test’s last execution status, so Never run tests inside the blast radius are visible at a glance.

You can copy the resulting test codes out as a worklist.

Two Different Empty Answers

An empty list is ambiguous, so Atlas distinguishes:

Nothing depends on this. The map knows about this node and nothing reaches it. A real, useful answer.
The map does not know about this yet. Nothing is linked to the node, or no routes are drawn. Not an answer — a prompt to go link some work.

If you get the second one regularly, the fix is linking nodes to requirements and folders rather than running deeper analyses.

Getting Good Answers

Impact analysis is only as good as the map underneath it.

Link nodes to real work. A node with nothing linked contributes nothing to the answer.
Draw dependency routes where they actually exist — shared services, auth, payment, anything several areas call.
Mark your critical journeys. Criticality is what lifts a test into Must retest.
Start shallow, widen if the answer looks thin.