Free test case template and generator

Preconditions: A verified account exists.

Test data: Registered email and its correct password.

Steps

1. Open the login page.
2. Enter the registered email.
3. Enter the correct password.
4. Select Log in.

Expected resultThe user lands on the expected page (dashboard or the page they came from) and sees their own account name.

Why it matters: If this fails, nobody can use the app.

Preconditions: Account registered as jane@example.com.

Test data: JANE@Example.COM and the correct password.

Steps

1. Enter the email with mixed upper and lower case.
2. Enter the correct password and select Log in.

Expected resultLogin succeeds. The email is treated as the same account.

Why it matters: Phones often capitalize the first letter of the email. Users get locked out for no reason if case matters.

Preconditions: A verified account exists.

Test data: ' jane@example.com ' (leading and trailing space)

Steps

1. Paste the email with a space before and after it.
2. Enter the correct password and select Log in.

Expected resultLogin succeeds, or the field trims the spaces automatically.

Why it matters: Copy and paste and phone autocomplete often add a trailing space.

Preconditions: Account password is Summer-Rain-2026.

Test data: summer-rain-2026

Steps

1. Enter the registered email.
2. Enter the password with different capitalization.
3. Select Log in.

Expected resultLogin fails with the generic error message.

Why it matters: A case-insensitive password is much easier to guess.

Test data: Valid credentials.

Steps

1. Enter the email and password.
2. Press Enter while the cursor is in the password field.

Expected resultThe form submits, same as selecting Log in.

Why it matters: Most people press Enter. If nothing happens they think the site is broken.

Preconditions: Credentials saved in the browser or a password manager (1Password, Bitwarden, iCloud Keychain, Google Password Manager).

Test data: Saved credentials.

Steps

1. Open the login page.
2. Use the autofill suggestion for email and password.
3. Select Log in.

Expected resultBoth fields fill correctly and login succeeds. Fields use autocomplete="username" and autocomplete="current-password".

Why it matters: Password managers are how many people log in. Broken autofill means more failed logins and support tickets.

Reference: NIST SP 800-63B-4 3.1.1; WCAG 1.3.5

Test data: Copied password.

Steps

1. Copy the password from another app.
2. Paste it into the password field.

Expected resultPaste works. Login succeeds with the pasted password.

Why it matters: Blocking paste pushes people to weaker passwords and fails accessible authentication.

Reference: OWASP Authentication Cheat Sheet; WCAG 3.3.8

Preconditions: The form has a show or hide password control.

Test data: Any password.

Steps

1. Type a password.
2. Select Show password, then Hide password.

Expected resultThe password is shown in plain text, then masked again. The cursor position and the value do not change.

Why it matters: Helps people avoid typos, especially on phones.

Reference: NIST SP 800-63B-4 3.1.1

Preconditions: User is logged out.

Test data: A deep link to a private page, for example /account/orders/.

Steps

1. Open the private page link while logged out.
2. Log in when redirected to the login page.

Expected resultAfter login the user lands on the page they first tried to open, not the home page.

Why it matters: Users who click a link in an email expect to land on that page after logging in.

Preconditions: The login URL accepts a return address, for example ?next= or ?redirect=.

Test data: ?next=https://evil.example

Steps

1. Open the login page with an external return address in the URL.
2. Log in with valid credentials.

Expected resultThe user stays on your own site. External return addresses are ignored.

Why it matters: Attackers use open redirects to send real login links that end on a fake site.

Reference: WSTG-CLNT-04

Preconditions: A verified account exists.

Test data: Registered email, wrong password.

Steps

1. Enter the registered email and a wrong password.
2. Select Log in.

Expected resultLogin fails with a generic message such as "Email or password is incorrect". The email stays filled in; the password field is cleared.

Why it matters: A clear but generic message helps users without telling attackers which part was wrong.

Reference: WSTG-IDNT-04; OWASP Authentication Cheat Sheet

Test data: An email with no account.

Steps

1. Enter an email that is not registered and any password.
2. Select Log in.
3. Compare the message, status and response time with LOGIN-011.

Expected resultSame message, same HTTP status and similar response time as a wrong password. Nothing reveals whether the account exists.

Why it matters: Different messages let anyone check which emails have accounts, which helps phishing and password guessing.

Reference: WSTG-IDNT-04; OWASP Authentication Cheat Sheet

Test data: Both fields empty.

Steps

1. Leave both fields empty.
2. Select Log in.

Expected resultThe form does not submit. Each field shows a clear required message next to it, and focus moves to the first empty field.

Why it matters: The most common mistake. A silent failure feels like a broken site.

Reference: WCAG 3.3.1; WCAG 3.3.2

Test data: Valid email, empty password.

Steps

1. Enter a valid email.
2. Leave the password empty and select Log in.

Expected resultRequired message on the password field only. No request is sent with an empty password.

Why it matters: Confirms validation targets the right field.

Reference: WCAG 3.3.1

Test data: jane@, jane.example.com, @example.com, jane@example

Steps

1. Enter each invalid email with any password.
2. Select Log in.

Expected resultA clear "enter a valid email" message for each, or the generic login error. No crash, no server error.

Why it matters: Typos in emails are common, especially on phones.

Reference: WCAG 3.3.3

Preconditions: Accounts exist with these emails.

Test data: jane+test@example.com, jane.o'neil@example.co.uk, j@sub.example.museum

Steps

1. Log in with each email and its correct password.

Expected resultLogin succeeds for each valid format.

Why it matters: Plus addresses and apostrophes are real and common. Rejecting them locks out real users.

Reference: RFC 5321 / 5322

Test data: Email of 255+ characters; password of 1,000+ characters.

Steps

1. Paste the long values into each field.
2. Select Log in.

Expected resultThe app handles it gracefully (generic error or field limit). No crash, no server error page, no frozen page.

Why it matters: Huge inputs can crash weak servers or expose error details.

Reference: WSTG-BUSL-01; WSTG-ERRH-01

Test data: <script>alert(1)</script>, ' OR '1'='1, emoji and accented letters

Steps

1. Enter each value in the email field and in the password field.
2. Select Log in.

Expected resultLogin fails with the normal error. The text is never run as code, and the page shows no database or server errors.

Why it matters: Login forms are a favorite target for injection attacks.

Reference: WSTG-INJT-01; WSTG-INJT-05

Preconditions: Account registered but email not yet confirmed (if your app requires confirmation).

Test data: Unverified account credentials.

Steps

1. Log in with the unverified account.

Expected resultThe app follows its rule (blocks or limits access) and offers a way to resend the confirmation email.

Why it matters: Without a resend option these users are stuck and leave.

Reference: WSTG-IDNT-02

Preconditions: An account that an admin has disabled, and one that was deleted.

Test data: Their last known credentials.

Steps

1. Try to log in with each account.

Expected resultLogin fails. The message does not reveal more than necessary.

Why it matters: Former users, banned users or ex-employees must not get back in.

Reference: WSTG-IDNT-04

Preconditions: Know the app's limit (for example 5 failed attempts in 15 minutes).

Test data: Correct email, wrong passwords.

Steps

1. Enter a wrong password until the limit is reached.
2. Try once more with the correct password.

Expected resultAfter the limit the account is temporarily locked or delayed, the user sees a clear message with what to do, and even the correct password is refused until the lock ends.

Why it matters: Without a limit, bots can guess passwords forever.

Reference: WSTG-ATHN-03; OWASP Authentication Cheat Sheet

Preconditions: Two devices or networks (for example wifi and mobile data).

Test data: Same email, wrong passwords.

Steps

1. Make half the allowed failed attempts from device A.
2. Make the rest from device B.

Expected resultThe account still locks at the limit. Switching device or IP does not reset the counter.

Why it matters: Attackers rotate IP addresses to get around per-IP limits.

Reference: OWASP Authentication Cheat Sheet

Preconditions: Account currently locked (LOGIN-021).

Steps

1. Use Forgot password on the locked account.
2. Complete the reset.

Expected resultReset works and the user can log in with the new password, following your lockout rules.

Why it matters: Otherwise an attacker can lock real users out on purpose.

Reference: OWASP Authentication Cheat Sheet

Preconditions: Limit is N failed attempts.

Steps

1. Make N-1 failed attempts.
2. Log in successfully, then log out.
3. Make 1 more failed attempt.

Expected resultThe account is not locked. The counter restarted after the successful login.

Why it matters: Real users who mistype now and then should not get locked.

Reference: WSTG-ATHN-03

Preconditions: Know when CAPTCHA shows (always, or after N failures).

Steps

1. Trigger the CAPTCHA.
2. Solve it and log in with valid credentials.
3. Try the audio or accessible alternative.

Expected resultCAPTCHA shows at the right moment, accepts a correct answer and has an accessible alternative.

Why it matters: A broken or inaccessible CAPTCHA blocks real people, not just bots.

Reference: WCAG 3.3.8; OWASP Authentication Cheat Sheet

Preconditions: Logged in.

Steps

1. Copy the URL of a private page.
2. Log out.
3. Paste the private URL in the same browser.

Expected resultThe user is sent to the login page. The private page is not shown.

Why it matters: On shared computers the next person must not get into the account.

Reference: WSTG-SESS-06

Preconditions: Logged in, viewed a private page with personal data.

Steps

1. Log out.
2. Press the browser Back button several times.

Expected resultPrivate pages are not shown from the browser cache, or they reload and redirect to login.

Why it matters: A common real-world leak on shared and library computers.

Reference: WSTG-ATHN-06

Preconditions: Know the idle timeout (for example 30 minutes).

Steps

1. Log in and leave the app idle past the timeout.
2. Try to open a page or save something.

Expected resultThe session has ended and the user must log in again. If the app warns before timeout, the user can extend it. Unsaved form data is not silently lost.

Why it matters: Balances security with not losing someone's work mid-form.

Reference: WSTG-SESS-07; WCAG 2.2.1

Preconditions: Logged in.

Steps

1. Open the login page URL directly.

Expected resultThe user is redirected to the app or sees that they are already logged in, not an empty login form.

Why it matters: Avoids confusion and accidental second accounts.

Preconditions: Logged in with the app open in two tabs.

Steps

1. Log out in tab 1.
2. Do an action in tab 2.

Expected resultTab 2 asks the user to log in again. No action is saved as the logged-out user.

Why it matters: Prevents strange states and actions after logout.

Reference: WSTG-SESS-06

Preconditions: Browser developer tools open (Application > Cookies).

Steps

1. Log in.
2. Inspect the session cookie.

Expected resultSecure and HttpOnly are set, SameSite is Lax or Strict, and the session ID changes after login.

Why it matters: Weak cookie settings make it easier to steal or fix sessions.

Reference: WSTG-SESS-02; WSTG-SESS-03

Test data: http:// version of the login URL

Steps

1. Open the login page using http:// instead of https://.

Expected resultThe browser is redirected to https:// before any form is shown. No credentials are ever sent over http.

Why it matters: Passwords sent over plain http can be read on public wifi.

Reference: WSTG-ATHN-01; OWASP Authentication Cheat Sheet

Steps

1. Log in with Remember me checked.
2. Close the browser fully and reopen the app.

Expected resultThe user is still logged in, for the advertised period.

Why it matters: Confirms the feature does what it promises.

Reference: WSTG-ATHN-05

Steps

1. Log in with Remember me unchecked.
2. Close the browser fully and reopen the app.

Expected resultThe user must log in again (or the app follows its documented rule).

Why it matters: People on shared devices rely on this.

Reference: WSTG-ATHN-05

Preconditions: Developer tools open.

Steps

1. Log in with Remember me checked.
2. Inspect cookies, local storage and session storage.

Expected resultOnly a random token is stored. The email or password is never stored in readable form.

Why it matters: Stored passwords can be stolen from the device.

Reference: WSTG-ATHN-05; WSTG-CLNT-12

Preconditions: Account has username jane_doe.

Test data: jane_doe and correct password.

Steps

1. Enter the username instead of the email.
2. Enter the password and log in.

Expected resultLogin succeeds. Username case rules match what signup allowed.

Why it matters: Confirms both identifiers lead to the same account.

Reference: WSTG-IDNT-05

Preconditions: No account exists for this Google or Apple email.

Test data: A Google account and an Apple ID.

Steps

1. Select Continue with Google (repeat with Apple).
2. Approve access.

Expected resultA new account is created or the user is asked to finish signup, and they land logged in.

Why it matters: First-time social login is where most social login bugs hide.

Reference: WSTG-ATHZ-05

Preconditions: A password account exists for jane@gmail.com.

Test data: Google account jane@gmail.com.

Steps

1. Select Continue with Google using the same email.

Expected resultThe app follows a clear rule (links the accounts after confirming, or explains how to log in). No duplicate account, no lost data.

Why it matters: Duplicate accounts confuse users and split their data.

Steps

1. Select Continue with Google.
2. Cancel or deny access on the Google screen.

Expected resultThe user returns to the login page with a short message. No error page, no half-created account.

Why it matters: People often change their mind at this step.

Preconditions: iOS app or web with Sign in with Apple.

Test data: Apple ID with Hide My Email selected.

Steps

1. Sign in with Apple and choose Hide My Email.
2. Trigger an email from the app (welcome or receipt).

Expected resultAccount is created with the relay address and app emails reach the user through Apple's relay.

Why it matters: If relay emails fail, iPhone users never get receipts or reset links.

Reference: Apple App Store Review Guideline 4.8

Preconditions: Two-factor enabled on the account.

Test data: Valid code from the authenticator app, SMS or email.

Steps

1. Log in with email and password.
2. Enter the current code.

Expected resultLogin completes. The code field accepts paste and the phone's one-time code autofill.

Why it matters: The happy path must be smooth or users turn two-factor off.

Reference: WSTG-ATHN-11

Preconditions: Two-factor enabled.

Test data: A wrong code, a code older than its validity window, and a code that was already used.

Steps

1. Enter each code in turn.

Expected resultEach is rejected with a clear message. Repeated wrong codes trigger a limit or lockout.

Why it matters: Six-digit codes can be guessed if there is no limit.

Reference: WSTG-ATHN-11; WSTG-ATHN-03

Preconditions: Two-factor enabled.

Steps

1. Enter the correct email and password.
2. On the code screen, open a private page URL directly instead of entering the code.

Expected resultThe user is sent back to the code screen. No private page is reachable until the code is verified.

Why it matters: A skippable second step means no second step.

Reference: WSTG-ATHN-11; WSTG-ATHN-04

Preconditions: Recovery codes generated.

Test data: One recovery code.

Steps

1. Log in using a recovery code instead of the two-factor code.
2. Try the same recovery code again.

Expected resultFirst use works and the user is notified by email. Second use fails.

Why it matters: Recovery codes are a backdoor if they can be reused.

Reference: WSTG-ATHN-11

Preconditions: SMS or email codes.

Steps

1. Request a new code several times quickly.
2. Try the first code after a newer one was sent.

Expected resultRequests are limited (cooldown shown). Only the newest code works.

Why it matters: Unlimited SMS sends cost you money and can be abused.

Reference: WSTG-ATHN-11

Test data: Registered email.

Steps

1. Request a login link.
2. Open the link (it logs in).
3. Log out and open the same link again.
4. Request a new link and wait past its expiry, then open it.

Expected resultThe link works once. Reused and expired links show a clear message and offer to send a new one.

Why it matters: A reusable link in someone's inbox is a permanent key to the account.

Reference: WSTG-ATHN-09

Steps

1. Request the link on a laptop.
2. Open the email and link on a phone.

Expected resultThe app follows a clear rule (logs in on the phone, or asks to confirm) and never leaves the user in a loop.

Why it matters: Very common in real life, often untested.

Preconditions: Mobile app with biometric login enabled.

Test data: Enrolled and non-enrolled finger or face.

Steps

1. Log in with biometrics.
2. Fail biometrics on purpose until the fallback appears.
3. Turn off biometrics in the phone settings and reopen the app.

Expected resultBiometric login works, failures fall back to password or PIN, and disabled biometrics never lock the user out.

Why it matters: Biometric edge cases cause lockouts and bad reviews.

Steps

1. Use Tab to move through email, password, show password, remember me, log in and forgot password.
2. Log in using only the keyboard.

Expected resultLogical focus order, visible focus on every control, no keyboard trap, and the cookie banner or chat widget does not hide the focused field.

Why it matters: Keyboard and screen reader users must be able to log in.

Reference: WCAG 2.1.1; 2.4.3; 2.4.7; 2.4.11

Preconditions: VoiceOver (iPhone or Mac) or NVDA (Windows).

Steps

1. Navigate the form with a screen reader.
2. Submit with errors.

Expected resultEach field has a spoken label (not only placeholder text) and error messages are announced when they appear.

Why it matters: Placeholder-only labels disappear and are often not read aloud.

Reference: WCAG 1.3.1; 3.3.1; 3.3.2; 4.1.3

Steps

1. Zoom the browser to 200%.
2. Resize to 320 pixels wide (or use a small phone).

Expected resultAll fields and buttons stay visible and usable without scrolling sideways. Tap targets are at least 24 by 24 pixels.

Why it matters: People with low vision zoom in. Small phones are still common.

Reference: WCAG 1.4.4; 1.4.10; 2.5.8

Preconditions: Real devices or a device cloud.

Test data: Valid credentials.

Steps

1. Log in on iPhone Safari (current iOS).
2. Log in on an Android phone with Chrome and with Samsung Internet.

Expected resultLogin works on each. The keyboard shows the email layout for the email field, and the page does not zoom in on focus.

Why it matters: Safari is about half of mobile visits in the US and Canada.

Reference: StatCounter US and Canada, September 2026

Preconditions: Network throttling (Slow 4G) or airplane mode.

Steps

1. Throttle the network to Slow 4G and log in.
2. Turn off the network right after selecting Log in.

Expected resultA loading state shows, the button cannot be pressed twice, and the user sees a clear "check your connection" message if it fails.

Why it matters: Many users log in on mobile data. Double submits create duplicate requests.

Preconditions: Logged in on device A.

Steps

1. Log in with the same account on device B.
2. Use the app on both devices.

Expected resultThe app follows its documented rule (both sessions stay active, or the older one is signed out with a clear message). Optionally the user is notified of a new sign in.

Why it matters: Unclear session rules confuse users and hide account sharing or takeovers.

Reference: WSTG-SESS-11

Test data: A test HTML page that loads your login page in an iframe.

Steps

1. Open the test page.
2. Check the response headers of the login page.

Expected resultThe login page does not load inside the frame (Content-Security-Policy frame-ancestors or X-Frame-Options is set).

Why it matters: Framed login pages enable clickjacking and fake overlays.

Reference: WSTG-CLNT-09

Preconditions: A verified account exists.

Test data: Registered email.

Steps

1. Select Forgot password on the login page.
2. Enter the registered email and submit.

Expected resultA confirmation message shows and the reset email arrives within a few minutes, in the inbox not spam.

Why it matters: If reset emails do not arrive, locked-out users are gone for good.

Reference: WSTG-ATHN-09

Test data: An email with no account.

Steps

1. Request a reset for an unregistered email.
2. Compare the message, status and response time with RESET-001.

Expected resultIdentical message, such as "If an account exists for that email, we sent a reset link". No email is sent. Timing is similar.

Why it matters: A different message tells anyone which emails have accounts.

Reference: WSTG-IDNT-04; OWASP Forgot Password Cheat Sheet

Test data: empty, jane@, plain text

Steps

1. Submit the form with each value.

Expected resultClear validation message next to the field. No server error.

Why it matters: Basic validation that is often missing on secondary forms.

Reference: WCAG 3.3.1

Preconditions: Reset email received.

Test data: New valid password.

Steps

1. Open the link from the email.
2. Enter and confirm a new password.
3. Log in with the new password.

Expected resultPassword changes. The old password no longer works. The new one does.

Why it matters: The whole point of the feature.

Reference: WSTG-ATHN-09

Preconditions: Password already reset with a link.

Test data: The same link.

Steps

1. Open the used reset link again.

Expected resultThe link is rejected with a clear message and an option to request a new one.

Why it matters: A reusable link in an old email is a permanent backdoor.

Reference: WSTG-ATHN-09; OWASP Forgot Password Cheat Sheet

Preconditions: Know the expiry time (for example 1 hour).

Steps

1. Request a link and wait past the expiry time.
2. Open the link.

Expected resultThe link is rejected with a clear message and an option to request a new one.

Why it matters: Old inboxes get hacked. Links must not live forever.

Reference: WSTG-ATHN-09; OWASP Forgot Password Cheat Sheet

Steps

1. Request a reset link (link A).
2. Request another (link B).
3. Open link A.

Expected resultLink A no longer works, or the app documents that only the newest link is valid. Link B works.

Why it matters: Fewer valid links means fewer chances for misuse.

Reference: WSTG-ATHN-09

Preconditions: Two accounts, A and B.

Steps

1. Inspect the reset link for account A.
2. Check whether it contains a user ID or email.
3. Change that part to account B and open it.

Expected resultThe token is long and random. Changing it fails. The link never contains a plain user ID or email that controls whose password changes.

Why it matters: Predictable tokens allow full account takeover.

Reference: WSTG-ATHN-09; OWASP Forgot Password Cheat Sheet

Preconditions: An intercepting proxy (for example OWASP ZAP or Burp Suite).

Test data: Host: evil.example

Steps

1. Send the reset request with a modified Host header.
2. Open the email that arrives.

Expected resultThe link still points to your real domain.

Why it matters: Host header poisoning sends real reset tokens to an attacker's site.

Reference: WSTG-ATHN-09; WSTG-INJT-17; OWASP Forgot Password Cheat Sheet

Preconditions: Developer tools open (Network tab).

Steps

1. Open the reset link.
2. Check the response headers and third-party requests on the page.

Expected resultReferrer-Policy is no-referrer (or strict). No analytics, chat or ad scripts on the reset page receive the URL with the token.

Why it matters: Tracking scripts can capture reset tokens from the address bar.

Reference: WSTG-ATHN-09; OWASP Forgot Password Cheat Sheet

Steps

1. Request a reset for the same email many times quickly.

Expected resultAfter a few requests the app slows down or pauses requests, with a friendly message. The account is not locked.

Why it matters: Prevents email bombing a user and protects your email reputation.

Reference: OWASP Forgot Password Cheat Sheet

Steps

1. Request a reset but do not open the link.
2. Log in with the current password.

Expected resultThe current password still works until the reset is completed.

Why it matters: Otherwise anyone can lock a user out just by requesting resets.

Reference: OWASP Forgot Password Cheat Sheet

Preconditions: Reset link open.

Test data: Too short, common, and valid passwords.

Steps

1. Try each password on the reset page.

Expected resultSame rules and messages as signup. Weak passwords are rejected.

Why it matters: Reset must not be a back door to weak passwords.

Reference: OWASP Forgot Password Cheat Sheet

Preconditions: Reset link open.

Test data: Two different values.

Steps

1. Enter different values in new password and confirm.

Expected resultClear mismatch message. Password not changed.

Why it matters: Prevents users locking themselves out again.

Reference: OWASP Forgot Password Cheat Sheet

Test data: The current password.

Steps

1. Set the new password to the current one.

Expected resultThe app follows its rule (allows it or explains why not). No crash.

Why it matters: Confirms the rule is intentional, not accidental.

Steps

1. Complete a password reset.

Expected resultThe user is sent to the login page to sign in with the new password (or the app documents why it logs in directly and still requires two-factor if enabled).

Why it matters: Auto-login after reset can bypass other protections such as two-factor.

Reference: OWASP Forgot Password Cheat Sheet

Preconditions: Logged in on device A.

Steps

1. Reset the password from device B.
2. Do any action on device A.

Expected resultDevice A is logged out, or the user was offered to log out everywhere.

Why it matters: If someone else was in the account, a reset must kick them out.

Reference: OWASP Forgot Password Cheat Sheet

Steps

1. Complete a reset.
2. Check the inbox.

Expected resultAn email says the password was changed, with a way to report it if it was not them. The email never contains the password.

Why it matters: Gives the real owner a chance to react to a takeover.

Reference: OWASP Forgot Password Cheat Sheet

Steps

1. Read the reset email on desktop and phone (Gmail, Outlook, Apple Mail).

Expected resultCorrect sender name, subject, branding, working link over https, expiry time mentioned, no broken images, readable on phones.

Why it matters: Users ignore emails that look like phishing.

Reference: WSTG-ATHN-09

Steps

1. Request the reset on a laptop.
2. Open the email link on a phone.

Expected resultThe reset works on the phone.

Why it matters: Most people read email on their phone.

Preconditions: Reset by code.

Test data: Wrong, expired and used codes.

Steps

1. Enter wrong codes several times.
2. Enter an expired code.
3. Reuse a code that already worked.

Expected resultWrong codes are limited (lockout or delay), and expired and reused codes fail with clear messages.

Why it matters: Short numeric codes are easy to brute force without limits.

Reference: WSTG-ATHN-09; WSTG-ATHN-03

Preconditions: Two-factor enabled on the account.

Steps

1. Reset the password.
2. Log in with the new password.

Expected resultThe two-factor step is still required.

Why it matters: Reset must not switch off two-factor.

Reference: WSTG-ATHN-09; WSTG-ATHN-11

Preconditions: Logged in.

Test data: Wrong current password, then the right one.

Steps

1. Go to settings and change the password with a wrong current password.
2. Try again with the correct current password.

Expected resultFirst attempt fails. Second succeeds. A confirmation email is sent.

Why it matters: Someone using an unlocked laptop should not be able to take over the account.

Reference: WSTG-ATHN-09; OWASP Authentication Cheat Sheet

Preconditions: Two accounts. Proxy or developer tools.

Test data: Another user's ID in the request.

Steps

1. Change your password while intercepting the request.
2. Replace your user ID with the other account's ID.

Expected resultRequest is rejected. Only your own password can change.

Why it matters: A classic and devastating access control bug.

Reference: WSTG-ATHN-09; WSTG-ATHZ-04

Preconditions: Keyboard and screen reader.

Steps

1. Complete the whole reset flow with keyboard only, then with a screen reader.

Expected resultLabels, errors and success messages are announced. Focus is visible and logical.

Why it matters: People who need reset the most are often already stuck.

Reference: WCAG 2.1.1; 3.3.1; 4.1.3

Preconditions: Logged in.

Test data: New name, phone, address.

Steps

1. Change each editable field and save.
2. Reload the page and log out and in again.

Expected resultChanges are saved, shown everywhere the data appears, and a success message confirms the save.

Why it matters: The basic promise of the settings page.

Test data: Empty required fields, invalid phone, too long values, script text

Steps

1. Save each invalid value.

Expected resultClear field messages, nothing invalid saved, and script text stored and shown as plain text.

Why it matters: Profile fields appear to other users and admins, so stored script is dangerous.

Reference: WCAG 3.3.1; WSTG-INJT-02

Preconditions: Logged in.

Test data: A new email you control.

Steps

1. Change the email.
2. Check both the old and the new inbox.

Expected resultThe current password (or re-authentication) is required, the new email must be confirmed by link or code before it is used for login, and the old email gets a notice with a way to undo.

Why it matters: Changing the email is the first step of most account takeovers.

Reference: OWASP Authentication Cheat Sheet; WSTG-ATHN-09

Preconditions: Another account exists with that email.

Steps

1. Change the email to the other account's email.

Expected resultRefused without merging accounts, using a message that does not reveal more than needed.

Why it matters: Merges or duplicates break both accounts.

Reference: WSTG-IDNT-04

Steps

1. Edit a field and try to leave the page without saving.

Expected resultThe user is warned before losing changes (or changes save automatically, as designed).

Why it matters: Silent loss of edits frustrates users.

Preconditions: Two accounts. Proxy or developer tools.

Test data: Another user's ID.

Steps

1. Change the user ID in the profile URL or update request.

Expected result403 or 404. Only your own profile can be read or changed.

Why it matters: Profile endpoints are a classic place for access control bugs.

Reference: WSTG-ATHZ-04; OWASP API1:2023

Test data: Time zones such as America/Toronto, America/Vancouver and America/New_York; dates near the daylight saving change

Steps

1. Change the time zone or locale setting.
2. Check dates in lists, emails and exports.

Expected resultDates and times show in the user's time zone consistently, including around daylight saving changes.

Why it matters: Wrong times on bookings and deadlines cause real problems.

Steps

1. Turn off each notification type (email, push, SMS).
2. Trigger events that would send them.

Expected resultTurned-off notifications are not sent. Required service emails (receipts, security alerts) still arrive as stated. Every marketing email has a working unsubscribe link.

Why it matters: Ignoring preferences breaks the law for marketing email and annoys users.

Reference: CAN-SPAM (US); CASL (Canada)

Preconditions: Logged in on two devices.

Steps

1. Open the sessions list on device A.
2. Sign out device B, then sign out all other sessions.

Expected resultThe list is accurate, and signed-out devices must log in again on their next action.

Why it matters: Users need a way to kick out a lost phone or an intruder.

Reference: WSTG-SESS-11

Preconditions: Account created with Google only, no password.

Steps

1. Try to unlink Google.

Expected resultThe app asks the user to set a password or another login method first, so they cannot lock themselves out.

Why it matters: A common way users lose access to their own accounts.

Preconditions: Account with data.

Steps

1. Request a data export.
2. Open the file.

Expected resultThe export arrives (immediately or by secure link), is complete, readable (for example JSON or CSV), contains only this user's data, and the link expires.

Why it matters: Privacy laws give users the right to their data; a leaky export link is a breach.

Reference: WSTG-ATHZ-04

Preconditions: Keyboard and screen reader.

Steps

1. Change settings using only the keyboard and with a screen reader.

Expected resultToggles announce their state (on or off), labels are clear, and save confirmations are announced.

Why it matters: Toggle switches are often unlabeled for screen readers.

Reference: WCAG 4.1.2; 4.1.3

Preconditions: An in-stock item.

Steps

1. Open a product page and select Add to cart.

Expected resultThe cart count updates, a confirmation shows, and the cart lists the item with the right name, option, price and quantity 1.

Why it matters: The first step of every sale.

Steps

1. Add the same item and variant twice.

Expected resultOne line with quantity 2 (or the app's documented rule). Totals are correct.

Why it matters: Duplicate lines confuse customers and can break discounts.

Preconditions: An item with size or color options.

Test data: Size M and size L.

Steps

1. Add size M, then size L.

Expected resultTwo lines with the correct variant, price and image each.

Why it matters: Wrong variant in the order means returns and refunds.

Preconditions: An item that requires a size.

Steps

1. Select Add to cart without choosing a size.

Expected resultClear message asking to choose a size. Nothing is added.

Why it matters: Orders with missing options cannot be fulfilled.

Reference: WCAG 3.3.1

Preconditions: Items in the cart.

Steps

1. Increase and decrease the quantity.
2. Remove one item.
3. Remove the last item.

Expected resultLine totals, subtotal and cart count update each time. An empty cart shows a friendly message and a way back to shopping.

Why it matters: Wrong totals after changes are a top checkout complaint.

Preconditions: Proxy or developer tools for the request test.

Test data: 0, -1, -5, 1.5, abc

Steps

1. Enter each value in the quantity field.
2. Send the same values directly in the update cart request.

Expected resultEach is rejected or corrected to a valid number, in the page and on the server. The total can never go negative.

Why it matters: Negative quantities can lower the total or create refunds. AI-built shops often miss this.

Reference: WSTG-BUSL-10; WSTG-BUSL-01

Test data: Max allowed, max+1, 999999

Steps

1. Enter each quantity.

Expected resultMax is accepted, larger values get a clear limit message. Prices do not overflow or show in scientific notation.

Why it matters: Huge orders can break totals and stock.

Reference: WSTG-BUSL-05

Preconditions: Item with 3 in stock.

Test data: Quantities 3 and 4.

Steps

1. Add 3, then try 4.

Expected result3 is allowed. 4 shows a clear stock message and is not allowed.

Why it matters: Overselling leads to cancelled orders and angry customers.

Preconditions: Last unit of an item in the cart of user A.

Steps

1. User B buys the last unit.
2. User A continues to checkout and pays.

Expected resultUser A is told before paying that the item is no longer available. A is never charged for an item that cannot ship.

Why it matters: A real race that happens on every busy launch or sale.

Reference: WSTG-BUSL-10

Preconditions: Admin access to change a price.

Steps

1. Add an item to the cart.
2. Change its price in the admin.
3. Return to the cart and checkout.

Expected resultThe cart and checkout show the current price, and the customer is told about the change before paying.

Why it matters: Charging a different price than shown is a legal and trust problem.

Reference: WSTG-BUSL-10

Steps

1. Add items as a guest, close the browser, return.
2. Log in.

Expected resultThe cart is still there, and guest items merge sensibly with any saved account cart.

Why it matters: Lost carts are lost sales.

Preconditions: Logged in on two devices.

Steps

1. Change the cart on device A.
2. Check out on device B without refreshing.

Expected resultDevice B uses the latest cart or warns that it changed. The order matches what the customer confirmed.

Why it matters: Orders that do not match what the customer saw lead to disputes.

Preconditions: Several items with different prices and quantities.

Test data: Include prices like 19.99 and 0.10 to catch rounding.

Steps

1. Calculate the expected subtotal, discounts, shipping, tax and total by hand.
2. Compare with the cart, checkout, confirmation page, email and admin order.

Expected resultEvery amount matches to the cent in all places.

Why it matters: Rounding and display errors are common and erode trust.

Preconditions: Proxy or developer tools.

Test data: price=0.01

Steps

1. Add an item while intercepting the request.
2. Change the price, item ID or total in the request.
3. Complete checkout in test mode.

Expected resultThe server recalculates prices from its own data. The order and charge use the real price.

Why it matters: Trusting prices sent from the browser lets anyone pay what they want.

Reference: WSTG-BUSL-10; WSTG-BUSL-01

Preconditions: Know your tax rules.

Test data: Addresses in a taxed US state, a no-sales-tax state (for example Oregon), and Canadian provinces with HST and with GST plus PST (for example Ontario and British Columbia).

Steps

1. Check out with each address.

Expected resultTax amount, name and rate match the rules for each address and are shown before payment.

Why it matters: Wrong tax costs you money or overcharges customers.

Test data: USD, CAD.

Steps

1. Switch currency and go through checkout.

Expected resultThe currency symbol and code are clear (US$ vs CA$), totals are consistent, and the charge is in the currency shown.

Why it matters: A plain dollar sign is ambiguous between the US and Canada.

Reference: WSTG-BUSL-10

Preconditions: A 10% code and a fixed amount code.

Steps

1. Apply each code.

Expected resultThe discount is correct, shown as its own line, and applied to the right items only.

Why it matters: Wrong discounts lose money or customers.

Preconditions: An expired code and a one-time code already used.

Test data: random text, expired code, used code, lower case version of a valid code

Steps

1. Apply each code.

Expected resultClear message for each. No discount for invalid ones. Case rules are consistent.

Why it matters: Leaky coupons spread fast on deal sites.

Reference: WSTG-BUSL-05

Preconditions: Two codes.

Steps

1. Apply two codes together.
2. Apply the same code twice.
3. Use a one-per-customer code again in a new order or a new account.

Expected resultOnly allowed combinations work. Limits are enforced on the server.

Why it matters: Stacking and reuse are the most common coupon abuse.

Reference: WSTG-BUSL-10; WSTG-BUSL-05

Preconditions: A code that needs a minimum of 50.

Steps

1. Reach 50, apply the code.
2. Remove items so the subtotal drops below 50.
3. Check out.

Expected resultThe discount is removed or the customer is told the code no longer applies.

Why it matters: A known trick to get discounts without meeting the minimum.

Reference: WSTG-BUSL-10

Test data: TEST, TEST10, WELCOME, SORRY10, company name + 10

Steps

1. Try common guessed codes.
2. Check page source for coupon codes in hidden fields.
3. Try many codes quickly.

Expected resultNo test codes work in production, no codes in the page source, and repeated attempts are limited.

Why it matters: Leftover test codes are found and shared within hours.

Reference: WSTG-BUSL-10

Preconditions: A fixed discount larger than a cheap item.

Test data: 20 off on a 15 item.

Steps

1. Apply the code to a cart worth less than the discount.

Expected resultTotal is 0 or the code is refused. Never below zero.

Why it matters: Negative totals can create store credit or refunds.

Reference: WSTG-BUSL-10

Test data: US ZIP 10001 and ZIP+4 10001-1234; Canadian postal code M5V 3L9 with and without the space; apartment or unit numbers.

Steps

1. Enter each address and continue.

Expected resultEach valid address is accepted. State or province lists are correct for the country.

Why it matters: Address forms built for one country block customers from the other.

Test data: Missing street, ZIP with letters, postal code 12345 for Canada, unsupported country

Steps

1. Enter each address.

Expected resultClear field-level messages. Unsupported countries are explained before payment.

Why it matters: Bad addresses mean failed deliveries.

Reference: WCAG 3.3.1; 3.3.3

Preconditions: Several shipping methods and a free shipping threshold.

Test data: Carts just under and just over the threshold.

Steps

1. Choose each method.
2. Test carts just below and at the free shipping limit.

Expected resultCosts, delivery estimates and the free shipping threshold are correct.

Why it matters: Shipping surprises are the top cause of abandoned carts.

Preconditions: Cheap local shipping and expensive international shipping.

Steps

1. Choose a local address and cheap shipping.
2. Go back, change to a far address, and continue without reselecting shipping.

Expected resultShipping cost is recalculated for the new address before payment.

Why it matters: A known way to pay local shipping for a far destination.

Reference: WSTG-BUSL-10

Steps

1. Tick billing same as shipping.
2. Untick it and enter a different billing address.

Expected resultThe address is copied when ticked and saved correctly in both cases.

Why it matters: Retyping addresses is a known frustration and an accessibility rule.

Reference: WCAG 3.3.7

Preconditions: Logged out.

Steps

1. Check out as a guest with a valid test card.

Expected resultOrder completes, confirmation page and email arrive, and the customer can find the order (email link or later account creation).

Why it matters: Forced signup is a top reason for abandoned checkouts.

Preconditions: Account with saved address.

Steps

1. Check out while logged in.

Expected resultSaved details are prefilled and editable. The order shows in the account order history.

Why it matters: Returning customers expect speed.

Reference: WCAG 3.3.7

Steps

1. Copy the URL of the confirmation or thank you step.
2. With a new cart, open that URL directly without paying.

Expected resultNo order is created and nothing is marked as paid. The user is sent back to the right step.

Why it matters: Skipping the payment step is a real and common logic flaw.

Reference: WSTG-BUSL-06

Steps

1. Reach the final review step.

Expected resultItems, quantities, prices, discounts, shipping, tax, total, addresses and a way to edit them are all visible before the pay button. Terms or return policy links work.

Why it matters: Clear review prevents mistakes, disputes and chargebacks.

Reference: WCAG 3.3.4

Preconditions: Completed order.

Steps

1. Check the confirmation page.
2. Check the confirmation email on desktop and phone.

Expected resultOrder number, items, totals, addresses and next steps are correct and match the payment. Email arrives in the inbox.

Why it matters: Customers who get no confirmation email contact support or dispute the charge.

Preconditions: Completed order.

Steps

1. Refresh the confirmation page.
2. Press Back to the payment step and Forward again.

Expected resultStill one order and one charge.

Why it matters: Duplicate orders mean double charges and refunds.

Reference: WSTG-BUSL-10

Preconditions: iPhone Safari and Android Chrome.

Steps

1. Complete checkout on each phone.

Expected resultFields are not hidden by the keyboard, autofill works for address and card, the pay button is reachable, nothing overlaps.

Why it matters: Most checkouts happen on phones.

Reference: WCAG 2.4.11; 2.5.8

Preconditions: Keyboard and screen reader.

Steps

1. Complete checkout with keyboard only, then with a screen reader.

Expected resultAll controls reachable, labels and errors announced, order total read correctly, no time limits without a way to extend.

Why it matters: Inaccessible checkouts lose sales and attract lawsuits in the US.

Reference: WCAG 2.1.1; 3.3.1; 3.3.4; 2.2.1

Preconditions: A completed order, logged in.

Steps

1. Open the order in the account order history.
2. Download or open the receipt or invoice.
3. Try to open another customer's order or invoice by changing the ID in the URL.

Expected resultOrder details and totals match the payment, the receipt shows business name, taxes and tax numbers where required, and other customers' orders are refused.

Why it matters: Invoices are needed for expenses and taxes, and invoice URLs often leak.

Reference: WSTG-ATHZ-04

Preconditions: Know the allowed types and size limit.

Test data: A small valid file of each allowed type.

Steps

1. Choose the file and upload.

Expected resultUpload succeeds with clear progress and confirmation. The file opens or displays correctly afterward.

Why it matters: The basic promise of the feature.

Reference: WSTG-BUSL-08

Steps

1. Look at the upload area before choosing a file.

Expected resultAllowed formats and maximum size are written near the control.

Why it matters: Users should not find out the rules by failing.

Reference: WCAG 3.3.2

Test data: .exe, .js, .html, .svg (if not allowed), .zip

Steps

1. Try to upload each file.

Expected resultEach is rejected with a clear message listing allowed types. Nothing is stored.

Why it matters: Blocked types are the first line of defense against malicious files.

Reference: WSTG-BUSL-08; OWASP File Upload Cheat Sheet

Preconditions: Proxy or developer tools.

Test data: A blocked file sent after the browser check.

Steps

1. Choose an allowed file, then swap it for a blocked file in the request.
2. Or remove the accept attribute from the file input in developer tools.

Expected resultThe server rejects the blocked file.

Why it matters: Browser checks are trivial to bypass.

Reference: WSTG-BUSL-08

Test data: virus.exe renamed to photo.jpg; photo.jpg.php; photo.pHp; photo.php%00.jpg; file with correct extension but wrong content

Steps

1. Upload each file.

Expected resultThe server checks real file content and extension rules. All disguised files are rejected.

Why it matters: Double extensions and fake content are classic tricks to upload code.

Reference: OWASP File Upload Cheat Sheet; WSTG-BUSL-09

Preconditions: Limit is for example 10 MB.

Test data: Files of 9.9 MB, 10 MB and 10.1 MB.

Steps

1. Upload each file.

Expected resultThe first two succeed (or the documented rule applies), the last is rejected with a clear size message, ideally before uploading the whole file.

Why it matters: Size boundaries are commonly off by one, and huge uploads can fill your storage.

Reference: OWASP File Upload Cheat Sheet

Test data: A 0 byte file with an allowed extension.

Steps

1. Upload the empty file.

Expected resultRejected with a clear message, or handled without errors.

Why it matters: Empty files often crash image processing.

Test data: 200+ character name; 'my file (1).pdf'; 'résumé-José.pdf'; '日本語.png'; '../../etc/passwd'; '.hidden.png'

Steps

1. Upload each file.
2. Check how the name is shown and downloaded.

Expected resultNames are stored safely (server-generated names are best) and shown as text. Path characters do not change where files are saved.

Why it matters: File names are user input and can break paths or pages.

Reference: OWASP File Upload Cheat Sheet; WSTG-ATHZ-01

Preconditions: Two accounts, A and B.

Steps

1. Upload a private file as A and copy its URL.
2. Open the URL logged out and as B.
3. Change the file ID or name in the URL.

Expected resultPrivate files need permission. Guessing or changing IDs does not reveal other people's files.

Why it matters: Public storage buckets have leaked millions of private documents.

Reference: WSTG-ATHZ-04; WSTG-CONF-11

Test data: An HTML or SVG file with a script (if those types are allowed).

Steps

1. Upload the file.
2. Open its URL directly.

Expected resultThe file downloads or displays as inert content. No script runs on your domain.

Why it matters: Uploaded HTML or SVG can steal sessions of anyone who opens it.

Reference: OWASP File Upload Cheat Sheet; WSTG-BUSL-09

Preconditions: A phone photo with GPS location in its EXIF data.

Steps

1. Upload the photo.
2. Download the stored copy and check its metadata.

Expected resultLocation and other personal metadata are removed if the image is visible to others.

Why it matters: Public photos with GPS data reveal where people live.

Reference: OWASP File Upload Cheat Sheet (re-encode images, strip metadata)

Preconditions: Photos taken in portrait and landscape on iPhone and Android.

Steps

1. Upload each photo.

Expected resultEach shows the right way up in previews, thumbnails and full size.

Why it matters: Sideways profile photos are a classic bug from EXIF orientation.

Preconditions: iPhone with the default camera format (HEIC).

Test data: A HEIC photo.

Steps

1. Upload a photo straight from the iPhone gallery.

Expected resultAccepted and converted, or a clear message explains the allowed formats.

Why it matters: iPhone is about half of US mobile users and HEIC is its default.

Test data: A 10,000 by 10,000 pixel image under the size limit; a tiny 1 by 1 image.

Steps

1. Upload each image.

Expected resultBoth handled without crashing. Large images are resized. Small ones follow your rules.

Why it matters: Huge dimensions can exhaust server memory.

Reference: OWASP File Upload Cheat Sheet (decompression bombs)

Test data: PDF, DOCX, XLSX; a password-protected PDF; a corrupted PDF.

Steps

1. Upload each document.
2. Download or preview it.

Expected resultValid files open intact. Protected and corrupted files get a clear message.

Why it matters: Corrupted uploads are often only noticed when someone needs the file.

Test data: 5 valid files; 1 invalid among 4 valid.

Steps

1. Upload all files together.

Expected resultValid files upload. The invalid one is clearly named and rejected without losing the others. Any file count limit is enforced and explained.

Why it matters: Batch uploads are where validation is often skipped.

Reference: WSTG-BUSL-08 (batch uploads)

Steps

1. Drag a file onto the drop area.
2. Upload a file using only the keyboard.

Expected resultDrop works with a visible drop state. A Browse button works by keyboard and screen reader.

Why it matters: Drag and drop alone excludes keyboard and many mobile users.

Reference: WCAG 2.1.1; 2.5.7

Preconditions: iPhone and Android.

Steps

1. Choose Take photo, then Photo library, then Files.
2. Deny camera permission once and retry.

Expected resultEach source works. Denied permission shows a clear message on how to allow it.

Why it matters: Most profile photos and documents are uploaded from phones.

Preconditions: Network throttled to Slow 4G.

Test data: A large valid file.

Steps

1. Upload the file and watch the progress.
2. Cancel halfway.
3. Upload again and turn off the network halfway.

Expected resultProgress is shown, cancel works and leaves no broken file, and a failed upload shows a clear retry option.

Why it matters: Without progress, users think a long upload has frozen.

Preconditions: A file already uploaded.

Steps

1. Replace it with a new file.
2. Delete it.
3. Open the old file URL.

Expected resultThe new file shows. After delete, the file is no longer reachable by its old URL (or follows your retention rule).

Why it matters: Deleted files that stay public are a privacy problem.

Reference: WSTG-CONF-04

Steps

1. Send an upload request while logged out.
2. Check the upload request for a CSRF token or SameSite cookie protection.

Expected resultLogged-out uploads are refused (unless public upload is intended). Cross-site requests cannot upload on a user's behalf.

Why it matters: Open upload endpoints get abused to host spam and malware.

Reference: OWASP File Upload Cheat Sheet; WSTG-SESS-05

Preconditions: The app says it scans uploads for malware.

Test data: The EICAR anti-malware test file (a harmless file every antivirus detects).

Steps

1. Upload the EICAR test file, alone and inside a ZIP if ZIPs are allowed.

Expected resultThe upload is blocked or quarantined with a clear message, and the file is never served to other users.

Why it matters: Proves the scanning you rely on is really running.

Reference: WSTG-BUSL-09; OWASP File Upload Cheat Sheet