Guide · authentication journeys
How to test signup, login and session flows
On this page
Test authentication as a complete account journey: create a synthetic account, complete verification, sign out, sign back in and check what happens when access expires. A successful redirect alone is not enough. Define the account state, expected destination and evidence for each transition before running the test.
Have a site ready to check? Test my site free. 10 browser runs a month after sign-up, without AI review. Add your URL and review a test plan before starting a run. See a sample report first.
First published · Facts checked
Prepare accounts and expected destinations
Use a staging or test-mode environment you own or have permission to test. Choose synthetic identities, an isolated test inbox and disposable records. Do not reuse a customer session or submit reset messages to someone else. Name the person responsible for cleanup before starting.
Write down the starting URL, account state and expected destination. A new account might need verification and onboarding; an existing verified account might go straight to its workspace. Treat those as separate cases. Use the signup form test cases for field-level validation; this guide follows the account across login and session changes.
Start signed-out checks in a fresh browser context. If an authenticated test starts with saved state, record that precondition: it tests the signed-in journey, not whether login itself worked. Keep authentication state out of source control and shared reports.
Signup and login test case matrix
| Case | Expected result to agree on | Evidence to capture |
|---|---|---|
| New account | Valid synthetic signup reaches the verification or onboarding step without duplicate accounts. | Starting URL, visible confirmation and account state from authorized test tooling. |
| Verification | A valid test token completes verification; an expired or reused token follows the specified error path. | Test inbox receipt and destination; mark delivery blocked if inbox access is unavailable. |
| Valid login | A verified synthetic user reaches the correct workspace, including an allowed requested destination. | Visible workspace identity and final URL, without publishing credentials. |
| Invalid login | Wrong credentials show a usable error without opening protected content. | Error text, keyboard focus and protected-route result. |
| Password reset | The authorized test inbox receives a reset link; completing reset allows the new credential to sign in. | Separate request confirmation, delivery and successful new login. |
| Logout | The app reaches its signed-out state; refreshing or reopening a protected route requires authentication. | Logout result plus a fresh protected-route request, not just a hidden menu. |
| Expired session | A deliberately expired synthetic session follows the documented reauthentication path. | Expiry setup, visible prompt and destination after signing in again. |
| Wrong role | A lower-privilege fixture cannot use a protected action reserved for another role. | UI result plus a separate server-side authorization test owned by engineering. |
Run the cycle without leaking state
- Create or reset the synthetic fixture. Record whether it is new, verified, locked or already onboarded.
- Exercise one transition and assert the meaningful result, such as the correct workspace, rather than only a success toast.
- Check refresh, a direct protected link and browser back after logout. Inspect access, not merely whether a previous screenshot remains in browser history.
- Test expiry with a sanctioned staging mechanism. Do not change production session policy or wait arbitrarily and assume expiry happened.
- Clean up accounts and application records, and record any manual cleanup still required. Retest the same case after a fix.
If your app offers social login, MFA or organization switching, give each a separate case and test identity. Missing provider access is blocked coverage, not a pass. Keep preview deployment protection and application login separate so a preview gate is not mistaken for an app defect.
Use Sybqa for a bounded browser check
Open Sybqa with your authorized test URL and describe the exact journey and expected result. Review the proposed plan before starting a run. Default read-only request restrictions can prevent authentication or account creation; a blocked step does not establish a product bug.
The CLI supports a supplied Playwright storage-state file for a synthetic account. This can exercise a signed-in route, but does not establish how that session was created. Separately configured test-transaction flows have their own test-mode requirements and cleanup limits. Do not assume an arbitrary production login, MFA challenge or email inbox can be automated.
Inspect the browser evidence and retain blocked or not-run outcomes. Browser checks do not prove token invalidation, tenant isolation or server authorization. Keep dedicated security and API tests for those properties. Add the verified cases to a small-team regression routine so future changes repeat the important transitions.
Common questions
What should a signup and login test cover?
Cover a new account, verification, valid and invalid login, reset, logout and an expired session with synthetic fixtures. Define the starting state and expected result for each; do not count unavailable inbox or provider steps as passed.
Does saved authentication state test login?
No. Saved state provides an authenticated starting point. Test the actual sign-in journey separately in a fresh context, then use saved synthetic state for checks that begin after login.
Does a browser authentication check prove the app is secure?
No. It gives evidence about the exercised browser path. Server authorization, token invalidation and tenant isolation require separate engineering-owned checks.
Sources
Related
Try Sybqa on your site
Explore bugs, UI consistency and user journeys from a reviewed plan. Inspect browser evidence and visual review leads in the report. The free plan gives 10 runs a month without AI review after you sign up. See pricing.
Add your site link here and it will be waiting in the console after you create an account. Then describe one journey to check and review the test plan before any run starts.