Skip to content

Prioritize testing from code changes (QA)

QA teams often re-run everything for every code drop, because it is hard to tell what a change really touched. That is slow and it hides risk — the tests most likely to catch the new defect get the same weight as tests that couldn't possibly be affected. Understand lets you turn a code delta into a ranked test scope: exercise the code that changed, plus everything that change can reach, first.

This page is a workflow that ties the change and impact tools together for a QA audience; each step links to its full how-to.

1. See what changed in this drop

Set the previous release (or the last tested commit) as a comparison database and open the Changed Entities Locator. You now have an exact, entity-level list of what is different — not a folder diff.

2. Expand to what the change can affect

Changed code isn't the whole risk; the code that depends on it is. Follow the ripple with change-impact analysis — callers, dependents, and references — to get the potentially-affected set. Those two sets together are your high-priority surface.

3. Map code to tests

Connect that surface to your test suite:

  • If you track which tests cover which areas, use architectures to group code into the functional areas your test plan is organized around, so "component X changed" maps to "run X's suite."
  • Use annotations to record, right on an entity, which test cases exercise it — a lightweight, in-tool traceability note that the next reviewer sees too.

4. Rank and run

Run the smoke and integration tests for the affected areas first, then widen as time allows. Changes that the metric deltas show also increased complexity (a jump in DiffCyclomatic, say) deserve extra scrutiny — more paths means more to test. See Export & track metrics over time, and use Where is my risky / complex code? to weight the standing hotspots — a small change in an already-complex unit is riskier than the same change elsewhere.

5. Automate the signal

In CI, produce the changed/affected set and the reports automatically on each build so QA gets the priority list without manual steps — see Run in CI (Jenkins).

This informs test selection; it doesn't replace your test strategy

Impact analysis is deliberately conservative and static — it tells you where risk could be, so you spend test effort well. Safety-critical programs still run their full required suites; use this to prioritize order and focus, not to skip mandated coverage.

Where to next