What to test in a SaaS app: the critical-path checklist

"Test everything" is not a plan, it is a way to end up testing nothing. You have limited time, and the honest goal is not total coverage, it is making sure the handful of flows that would actually hurt you never break silently. Those are your critical paths: the ones that lose money, lock out customers, or quietly tank a metric when they fail. Here is the short list worth covering for almost any SaaS, and what to actually check in each.

The critical paths

For each of these, the test should do what a real user does, in a real browser, and assert the outcome the user would care about, not just that a page returned a 200.

• Signup. A new user creates an account with fresh details and lands on a working, personalized first screen. Assert the account is really created and the welcome state renders, not a blank shell. This is the flow every customer completes and the one most likely to fail quietly.
• Login. A returning user signs in from a clean session and stays signed in across a reload. Assert the session persists, and that a wrong password shows a clear error without looping or locking instantly.
• Password reset. A locked-out user requests a reset, receives the email, follows the link, sets a new password, and can log in with it. Assert the email arrives and the link works, the step most tests skip.
• Checkout or upgrade. A user pays with a test card and actually gets what they paid for. Assert the success state renders and the account is genuinely unlocked, not still behind the paywall it just paid to remove.
• The core action. Whatever your product exists to do, sending the message, creating the project, running the report, needs to work end to end for a real user. This is your "aha" moment, and a break here means new users never see the value.
• Onboarding and invites. If getting started or inviting a teammate is part of activation, test it. A broken invite link or a stuck onboarding step silently kills activation.
• Account and cancellation. Updating billing, changing a plan, and canceling should all work. A broken cancellation flow is both a support burden and, in some places, a compliance risk.

You will have a few more that are specific to your product. The test is simple: if this flow broke for an hour and nobody noticed, would it cost you money or customers? If yes, it is a critical path.

What to assert, and what to watch

For every flow above, a good test goes past "the page loaded":

1. Drive the real steps a user takes, in a real browser, against the real deployment.
2. Assert the meaningful outcome: the account exists, the data loaded, the payment unlocked access, the message sent.
3. Watch the console and network the whole time, so a page that looks fine but silently failed a request is still caught.
4. Use fresh data each run, so today's run does not collide with yesterday's leftover state.

Keep them green on every deploy

A checklist you run by hand once a month is a checklist that catches regressions a month late. The point of identifying your critical paths is to put them on autopilot: run them on every deploy so a change you shipped gets caught immediately, and on a schedule so drift in a third party gets caught even when you did not ship. The list is short precisely so that running all of it automatically, every time, is cheap.

How VeriWasp fits

VeriWasp lets you describe each of these flows in plain English once, then runs them in a real browser on every deploy and on a schedule, with no test pipeline to maintain. Each run asserts the real outcome, watches the console and network, and reports any failure tied to the exact step with the evidence attached. It is the fastest way to turn this checklist from a document into a safety net that actually runs.

You can set up your critical paths with a few free runs, no card required. Skip "test everything." Cover the flows that would hurt, and keep them green automatically.