How to build a regression suite for a product with no tests

Ask the owner which paths earn revenue. For a shop that means browse, cart, pay and receive confirmation, while a billing tool runs through create customer, raise invoice, record receipt and export statement. If analytics exist, check which pages and API endpoints draw the most traffic, because real usage often differs from what the team assumes about its own product.

Write each journey from the user’s side. Name the goal the user is chasing, such as paying a supplier bill or downloading last quarter’s statement, rather than the button labels that happen to exist today.

Five to ten journeys is plenty. Skip the settings menus. Walk each journey through a live build with the product owner watching, and fix any step where the owner says real users would act differently from the script.

A case holds a title, a starting state, numbered steps, an expected result and the test data it needs, nothing more than that. Keep it to one idea. Split cases that check six things.

Use a spreadsheet or a tool such as TestRail, whichever the team will actually open, and keep sample data beside it for every case. Typical records include a customer with two addresses, a coupon that expires tomorrow and a product with zero stock, since those expose the awkward branches. A tester should be able to hand the sheet to a new colleague who then finishes every case without asking a single question.

Add the awkward variants next to each happy path, such as an empty field, a duplicate email, a refund and an expired session. Each variant is its own case.

Mark every case high, medium or low by asking what it costs if the journey breaks and how likely a break is given recent code changes. High cost and high likelihood goes first.

Pull out the dozen cases that prove the product is alive, meaning it opens, a user logs in and one order goes through. That is your smoke set. It runs in ten minutes. Recent bug reports and files changed in the last three releases show where the code is shaky, so cases touching those areas deserve a high tag.

The full regression pass covers everything else, with smoke running on every build and the full pass running before each release goes out.

Automate the smoke set first. It runs most often. Pick cases that are stable, repetitive and have clear expected results, and leave visual judgement and rarely used screens to manual testing.

Choose a framework your developers already read, such as Playwright or Cypress for browser journeys, paired with plain HTTP checks for the API layer beneath. Run them from the build server. Nobody has to remember.

Skip any screen that changes every sprint, because the upkeep of rewritten locators and updated expectations costs more than the checks ever save. Teams that automate a flaky screen end up rerunning failed jobs until they go green, and that trains everyone to ignore red results.

Add the run to the release checklist. Name an owner for the run. A suite nobody runs is just paper.

Add one case for every bug fixed from now on, so that in six months the suite reflects the faults your product actually has. Review it every quarter by deleting cases for removed features, merging duplicates and promoting the cases that caught real faults, so the pass stays short enough to run.

Put failures first on the agenda. Start there next week.