Sync
One click turns your test folders into a first map. Run it again any time — it gives the same result for the same folders.
Atlas gives you the list of test cases to rerun, sorted by how urgent they are, and each one says why it's on the list. It works from a simple map of your app: its areas and screens, and what depends on what.
Pick the part of the map that changed. Atlas finds everything that depends on it and sorts the test cases into three buckets: Must retest, Should retest and Consider.
A diagram, not a screenshot. Look at the icon on each row: two tests can both be must retest for different reasons, and the list tells you which.
Hawzu builds a first version from what you already have. You tidy it up.
One click turns your test folders into a first map. Run it again any time — it gives the same result for the same folders.
Hawzu reads your documents in Canon and suggests the areas and screens your folders never named. Each suggestion shows where it came from, and you approve them one by one.
Rename things so people recognise them, link requirements to the parts they describe, draw a line where one part depends on another, and mark the journeys that would stop a release if they broke. Your edits survive every later sync.
Items are joined by two kinds of line: navigation (a user goes from this screen to that one) and dependency (this part breaks if that part changes). Dependency lines are what the retest list follows.
A five-step purchase with four tested steps and no test on checkout isn't 80% covered — nobody completes 80% of a purchase. Atlas shows the weakest step, not a comforting average.
Rename an item, move it somewhere sensible, sync again next month — your changes stay. Anything you deleted stays deleted.
The whole project works from one map, so a retest list is something the team can discuss with the same picture in front of them. Everyone can read it; only some roles can change it.
Every item on the map is coloured by how its tests are doing, and colours add up to the area above. An empty heading isn't flagged as a problem — only something that has work linked to it and no test reaching it.
Want to know how one test run went instead of "what has ever passed"? Narrow the map to that run.
Suggestions from your documents arrive as a draft. You go through them and approve what's right. Nothing is accepted by default.
Must retest, Should retest, Consider — and every test case says why it's in its bucket. No percentage you'd have to take on faith.
Atlas is built from your test folders, your specs, the requirements you link and your edits. It shows what your team believes the product is — so where that's incomplete, it shows up as a gap.
It never is. Somebody opens Atlas, picks the auth item, and gets twenty-eight test cases back — seven of them must retest, three of those on the sign-up journey, one never run at all. The estimate changes in the meeting instead of the Thursday before release, and the list goes straight into the test run because every row already says why it's there.
Atlas maps what your product is made of. Canon holds what it promises. Generate test cases from a map item and the AI gets both: where the feature sits, and what it's supposed to do.
Every feature on every plan. Free for five people, $20 per member after — no credit card.