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.
Turn user journeys into tests Planned
Describe each existing workflow and its expected outcome once; review the proposed checks.
Run checks consistently Planned
Group the checks as a regression set and run it against staging after each build.
Keep tests aligned with changes Planned
When a page changes, review the suggested step update instead of rewriting the check.
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
Sample screenshot
c-07 final stateScreenshot not included in this sample. - fill sign-up form
- read test inbox
- open link
- 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
Sample screenshot
c-08 at failureScreenshot not included in this sample. - open /settings/account
- change email
- confirm via test inbox
- reload
- 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
Sample screenshot
c-09 final stateScreenshot not included in this sample. - change password
- sign out
- sign in with new password
- 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
Sample screenshot
c-10 final stateScreenshot not included in this sample. - add item
- checkout
- select saved card
- confirm
- assert order number
Order history lists the new order c-11 · 8sPassedExpected: Latest order appears firstActual: Latest order firstShow execution detailsHide execution details
Sample screenshot
c-11 final stateScreenshot not included in this sample. - open /orders
- assert first row contains order number
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.