Skip to main content
LogisticsTest design

A QA team inherited a large web app, thin documentation and a release date

Taking over an unfamiliar application means learning it and testing it at the same time. Here is how a QA team gets a map of the app, a first list of reviewed bugs and the start of a regression suite.

Scenario: A QA team taking over testing of an acquired customer portal

Problem

There was no up-to-date map of the portal's pages and flows, validation rules were unknown, and the release was weeks away.

Solution

An autonomous exploratory run that maps the app, probes its inputs and files reviewed bugs, then saves the flows it found as a suite.

Capabilities usedAutonomous exploratory tester + App mapInput-validation tourBug triageCompare a crawl with the last oneSave discovered flows as a suite

The problem

The company had acquired a customer portal, and its QA team took over testing it with a release a few weeks away. Documentation was thin, few tests existed, and every release changed pages the team was still learning.

  • There was no up-to-date map of the portal's pages and flows.
  • Input validation rules were unknown until something broke.
  • After each release there was no quick way to see which pages had changed.
  • Exploratory findings lived in notes rather than in a runnable suite.

The solution

QAEverest explores; the QA team reviews what it found and decides what becomes a bug and what becomes a test.

  1. Map the app

    Autonomous exploratory tester + App map

    Given a URL and a login, it signs in — even through a login form inside a frame — crawls the portal, invents realistic user flows, runs them for real and triages what broke. Every run draws a map of the pages it reached, as a graph or a tree, coloured by what happened on each page. A cheaper map-only run draws the map without generating or running anything.

  2. Probe the inputs

    Input-validation tour

    An optional tour probes the text fields on the pages it crawled — by default up to 12 per page and 60 per run — with boundary, negative and valid values, and flags the rules the app fails to enforce.

  3. Review bugs before they are filed

    Bug triage

    Each bug opens with its steps, the failed one marked, expected against actual and the screenshot. Filing it is one click after review; it never writes to the tracker on its own.

  4. See what a release changed

    Compare a crawl with the last one

    After a release, a re-crawl marks pages new, changed or removed. The comparison is deliberately cautious, so pages one run never reached are counted separately and changing data does not read as a changed app.

  5. Turn findings into regression

    Save discovered flows as a suite

    Tick the flows a run discovered and save them as a UI automation suite, one test case per flow. Logins are never copied into the steps — a flow that types a password is skipped — and the app's login is added once under the suite's pre-steps. Saved steps follow the environment's base URL, so a flow found on staging runs on production unchanged.

What changes

  • The team starts from a map of the portal instead of a blank page.
  • Validation gaps are found by a systematic pass and reviewed by the QA team before anything reaches the tracker.
  • Each release shows which pages are new, changed or gone.
  • Exploratory runs become the first version of the regression suite.

Read more

Facing a problem like this?

Bring one of your own stories, suites or release questions to a demo and we will walk through it in the product with your QA team.

Book a demo Start free

More case studies

B2B SaaSScenario

A nightly suite that was red so often, its results stopped being read

Problem

The same few tests failed most nights, real regressions hid among them, and a screenshot showed that a step failed but not why.

Solution

Flaky tests separated from regressions, failures replayed with an AI root cause, and seeded defects that show what the suite really catches.

Read the case study