Impact Analysis

3 min read

Pick the part of your app that changed, and Atlas gives you a list of test cases to retest — sorted into Must retest, Should retest and Consider, with the reason each one is there.

Example: your map says Checkout depends on Payment service. The payment service changes. You run impact analysis on Payment service, and Checkout’s tests appear in the retest list alongside the payment service’s own tests.

Run an Impact Analysis

Impact analysis starts from an item on the map — one node, such as a screen, a feature or a service.

Open Atlas and find the item that changed.
Start the analysis in one of these ways:
- Tree view: open the ⋮ menu on the item’s row and choose If this changes…
- Map view: right-click the item and choose If this changes…
- Inspector (the details panel that opens when you select an item): select the target button at the bottom, What else moves if this changes?
The panel If ”…” changes opens on the right with the results.

The Tree menu and the inspector button appear only for people who can edit the map. If you can only view it, use the Map view and right-click the item.

If what changed is a requirement or a test case, start from the map item it’s linked to.

What Atlas Looks At

From the item you start from, Atlas collects:

the item itself and everything nested inside it;
items that depend on it, following dependency routes up to two steps out (if A depends on B and B depends on your item, both show up);
every test case linked to those items, through their folders and requirements;
any journeys that pass through them.

Navigation routes are not followed — only dependency routes. That’s why the direction of your dependency routes matters: see Get the dependency direction right.

Reading the Results

The panel shows three numbers — Tests, Must retest and Never run — then:

Inside the blast radius and untested — affected items with no tests at all. Your biggest risk.
Journeys crossing this change — each affected journey and how many of its steps are affected.
The retest list, in three tiers.

The three tiers

Tier	A test lands here when…
Must retest	It’s on the item that changed, it’s on a Critical journey the change reaches, or its last run failed or was blocked
Should retest	It’s one step away from the change, or it has never been run
Consider	It’s further out, but still reachable

There’s no score — just these three groups. Each row shows the test’s code, title and last result.

Every test says why it’s there

Each row has a small icon for its main reason — on an affected journey, or linked to an affected item directly, through a requirement or through a folder. Hover it to see every reason. The tier and the reason are separate: two tests in Must retest can be there for different reasons.

Copy the list

Copy N test codes at the bottom of the panel copies every test code, one per line — handy for building a test run.

When the List Is Empty

Atlas tells two kinds of empty apart:

“Nothing on the map links to this yet” — the item has no linked folders or requirements, so Atlas can’t tell. Link some work to the item first. See Link a requirement to a node.
“No test cases reach any affected area” — Atlas found affected items but none of them has tests. That’s the gap you need to fill.

Getting Good Answers

Link items to real work. An item with nothing linked adds nothing.
Draw dependency routes where they really exist — shared services, login, payments, anything several parts of the app use.
Mark your critical journeys. That’s what puts a test into Must retest. See Journeys.