Regression testing

Keep existing workflows in view as your product changes.

After each release, behaviour that worked before can break in places nobody touched on purpose. Checking every existing workflow by hand does not scale with release frequency.

A regression suite is the set of checks that re-runs existing behaviour after each change; this page describes how one would be organized.

Example scenarios

  • Sign-up with email confirmation
  • Account changes (email, password, profile)
  • Checkout with a saved payment method

Proposed workflow

Each step names the capability it relies on and that capability's current stage. Steps that rely on a Planned capability describe intended use.

  1. Turn user journeys into tests Planned

    Describe each existing workflow and its expected outcome once; review the proposed checks.

  2. Run checks consistently Planned

    Group the checks as a regression set and run it against staging after each build.

  3. Keep tests aligned with changes Planned

    When a page changes, review the suggested step update instead of rewriting the check.

  4. Investigate failures with context Planned

    Open failed checks with the screenshot and execution details to decide whether behaviour or the test changed.

Sample output

Checks from the sample report that match this use case. Open a check to see its execution details.

  • Sign-up with email confirmation c-07 · 33sPassedExpected: Confirmation email link activates the accountActual: Account active; redirected to onboardingShow execution detailsHide execution details
    Screenshot not included in this sample.
    1. fill sign-up form
    2. read test inbox
    3. open link
    4. assert /onboarding
  • Account email change c-08 · 29sFailed Needs reviewExpected: New email shown in profile after confirmationActual: Profile still shows old email after confirmationShow execution detailsHide execution details
    Screenshot not included in this sample.
    1. open /settings/account
    2. change email
    3. confirm via test inbox
    4. reload
    5. assert email field

    Requires review: Behaviour change or stale cache; needs a human decision

  • Password change c-09 · 16sPassedExpected: Login works with the new passwordActual: Login succeededShow execution detailsHide execution details
    Screenshot not included in this sample.
    1. change password
    2. sign out
    3. sign in with new password
    4. assert dashboard
  • Checkout with saved payment method c-10 · 25sPassedExpected: Order placed without re-entering cardActual: Order placed; order number shownShow execution detailsHide execution details
    Screenshot not included in this sample.
    1. add item
    2. checkout
    3. select saved card
    4. confirm
    5. assert order number
  • Order history lists the new order c-11 · 8sPassedExpected: Latest order appears firstActual: Latest order firstShow execution detailsHide execution details
    Screenshot not included in this sample.
    1. open /orders
    2. assert first row contains order number
Product preview. Sample data.

Open the full sample report

Limitations

  • The team defines which workflows belong to the regression set
  • Test data and environment access are prepared by the team
  • Web applications only

What would you like to stop checking manually?

Tell us about your application and testing challenges. We'll follow up about early access and whether Testivra fits your needs.