BREAKYOURAPP · TESTING NOTES
SaaS QA Checklist: Workflows, Persistence and Tenant Isolation
Published · About BreakYourApp
A SaaS release can look correct while losing saved data or exposing another account’s records. Start with a small set of business outcomes you can prove, then expand coverage. This checklist separates manual investigation from checks you can configure in BreakYourApp.
Start with one critical business outcome
Pick the action that would hurt a customer most if it failed: creating a project, saving a booking, or updating a record. Define what one successful completion means before you run the test. A completed click is execution evidence; it is not proof that the business outcome occurred.
Use a unique synthetic value and an empty starting state. For a project workflow, specify: one matching project appears, the declared creation request returns the expected success, and the project remains after a refresh. If the value was already visible, the new action has not been demonstrated.
| Test condition | Expected observation | Evidence or interpretation |
|---|---|---|
| Create one project | Exactly one new row with a unique value | Matching request response, row count and visible result |
| Refresh the page | The same row is still present | Result text and count after reload |
| Repeat the final submission | No unintended duplicate | One matching row after the repeated action |
Check failure handling, not just the happy path
Try an empty required field, malformed input, numeric boundaries and a long string. Observe whether the application explains the problem and prevents an invalid state. These are test ideas: an automatically exercised form does not by itself verify every business rule.
Simulate an API error on staging and compare it with the visible UI outcome. A success message paired with an HTTP 500 is a meaningful contradiction. Decide how retry should work: can the customer recover without creating two records? A second submission can reveal duplicate creation, but it does not prove every concurrent race condition is covered.
Use two accounts to verify privacy
Create a private synthetic record in account A. Sign in as account B in a separate browser context and prove B really signed in using a marker from B’s own authenticated page. Then open A’s known resource and its declared JSON endpoint. An anonymous browser supplies a separate control.
A hidden UI is insufficient if the response body contains the private value. A 403 status is also insufficient when the same body exposes it. Compare data presence, session identity and response status together. Do not use an account that is legitimately permitted to share the record.
| Test condition | Expected observation | Evidence or interpretation |
|---|---|---|
| Owner A | Private marker present | Establish the baseline |
| Account B | Private marker absent | Verify B login before testing access |
| Anonymous | Private marker absent | Use a fresh isolated context |
Turn uncertainty into an explicit result
Use passed only when the defined assertion was observed. Use failed when observed behavior contradicts it. Use blocked when login, baseline, response parsing or the execution budget prevents a verdict. Keep unexecuted test ideas separate from completed checks.
Review failures with a human and record expected behavior, actual behavior, steps and available evidence. Severity depends on impact and exposure, not merely the type of test. Verify that the sharing policy actually promises isolation before declaring a security vulnerability.
Configure this in BreakYourApp
Enter an authorized, reachable staging URL. Add a dedicated account and a critical journey with exact control labels, unique expected text and, when applicable, the result selector and creation request path. Enable repeated submission only for a disposable, non-destructive staging action.
For isolation testing, provide accounts A and B, a primary-only UI resource, a unique private marker, B’s authenticated homepage marker, and optionally one same-origin JSON GET endpoint. Product context helps prioritize supported checks, but it does not turn every proposed case into an executable test. Internal server code, every endpoint and every possible user journey remain outside this checklist’s automatic coverage.