Website Login and Password Reset: Acceptance Tests Before Launch

A customer remembers buying from your business, but cannot remember the password. The reset email arrives, the link opens on a phone, and the website sends them back to the login screen without explaining what happened. Your team demonstrated successful sign-in before launch. Nobody demonstrated how a real customer gets back in.

Before accepting a website with customer accounts, test the complete access journey: ordinary login, failed attempts, password recovery, expired and reused links, cross-device completion, session expiry and logout. Agree the expected result before the demonstration and record what actually happened. A polished login form proves very little about the recovery path behind it.

This guide gives Indian business owners and project managers an original acceptance framework for that review. The examples are fictional commissioning exercises, not WSC client findings. These checks complement developer verification and specialist security assessment; they do not establish that a system is free of vulnerabilities.

Define what the customer account promises

Start with the task that needs an account. A trade buyer might revisit quotation requests. A training customer might manage enrolments. An online shopper might inspect previous orders. Write the actual benefit in one sentence before discussing authentication features. If the task can work safely without registration, explain why a compulsory account is being introduced.

Separate customer accounts from employee administration. A customer recovering access should not enter the same operational workflow used to grant staff permissions. Likewise, authentication answers who is signing in; authorisation determines what that identity may do. This article concentrates on the first question and the lifetime of the resulting session.

Put the account journey into your website design brief: eligible users, identifier, verification method, recovery channel, supported devices and the person who approves exceptions. Check that the brief describes the recovery journey as clearly as the initial sign-in screen.

Specify behaviour instead of reassuring adjectives

“Secure and user-friendly login” cannot be witnessed as a single outcome. “A customer can use a password manager, recover through their verified mailbox, see an understandable expired-link message and sign out of the current device” gives the team observable work. Ask the supplier to identify which behaviours come from an identity provider and which are implemented in the website.

List special situations separately: invitation-only accounts, suspended customers, accounts awaiting verification, social sign-in, multifactor authentication and lost access to the recovery mailbox. Do not assume a password-reset feature solves all of them. Agree which are included now, which require a different process and which are outside the launch scope.

Prepare a safe, repeatable demonstration

Use a production-like test environment with harmless customer records and mailboxes your team controls. Create an active account, a second independent account, an unverified account if supported, and an address that is not registered. Give each exercise an identifier so screenshots and observations can be connected without recording passwords or live reset tokens.

Ask for a short rule sheet before testing: recovery-link lifetime, resend behaviour, applicable throttling, session duration, remembered-device behaviour and what a password change does to existing sessions. The supplier should explain the rationale for these choices. There is no single timeout that suits every public shop, professional portal and sensitive business application.

Keep a normal browser profile, a separate signed-out context and an ordinary phone available. Private browsing is useful for isolating sessions, but it does not reproduce every customer's browser configuration. Include at least one supported configuration with normal saved credentials and another without them. Record the device and browser used when a failure occurs.

Agree a bounded test plan. Repeated failed attempts should be demonstrated with authorised test accounts and a controlled limit, rather than by sending large volumes of requests to the public website. If an email or identity dependency is shared with production, ask the developer how the exercise will avoid disturbing real customers.

Test ordinary login before testing its exceptions

Begin at the page a returning customer is likely to use, not a special demonstration URL. Sign in using the agreed identifier and check that the destination belongs to the intended account. Confirm that the page makes the signed-in identity sufficiently clear to avoid confusion when several people use one office computer.

Then sign out and repeat with saved credentials. Test keyboard navigation, visible labels, password visibility controls if supplied, and the behaviour when the onscreen keyboard appears. Check that error messages remain readable rather than disappearing behind a banner or forcing the customer to search the page.

Allow the assistance customers already use

Try browser autofill and a password manager; also try pasting into the password field. W3C's accessible-authentication guidance explains how assistance can reduce the need to memorise or transcribe credentials. A form that blocks those mechanisms needs careful review, not praise for appearing stricter.

Ask developers to inspect field semantics as well as appearance. MDN documents distinct autocomplete tokens for usernames, existing passwords, new passwords and one-time codes. Correct hints support assistance, although actual behaviour must still be checked in the browsers your customers use.

Make failure understandable without exposing account membership

Try an incorrect password and an unregistered identifier. The customer should have a useful next step without the public interface unnecessarily confirming which addresses hold accounts. OWASP's authentication guidance discusses generic failure responses and controls against automated attempts.

Ask how legitimate customers recover when an attempt limit is reached. Demonstrate the agreed waiting period or recovery route. A temporary protection should not leave the business inventing an insecure manual bypass. Compare the displayed explanation with the rule sheet and record any difference for resolution.

Follow password recovery beyond the email

Open “forgot password” from the actual login page and submit the active test account. Keep the initial response separate from evidence that mail was delivered. A request can be accepted while the message is delayed, filtered or rejected downstream. Record submission and receipt times as observations from this exercise, not as a general delivery guarantee.

Repeat with the unregistered address. The outward response should follow the agreed privacy rule. Your authorised reviewers can use internal test evidence to distinguish outcomes; the public form should not need to disclose account membership to be helpful.

Inspect the message as a customer would

Check sender identity, understandable wording, the expected website destination and the explanation for an unsolicited message. The email should make the next action clear without including the password. If the business serves customers using several common mail apps, include representative ones in the supported test set.

Open the link and set a new password using the stated policy. Sign in through the ordinary login route afterwards. Verify that the old password fails and that the expected account remains intact. Do not stop at the screen saying the change succeeded; the next normal login is part of the exercise.

Test the lifecycle of the link

OWASP's forgot-password guidance recommends securely generated, single-use tokens with an appropriate expiry and protections against excessive requests. Ask the developer for implementation evidence separately from the customer demonstration.

For the witnessed exercise, use one link successfully, then try it again. Request another link and let it expire under a controlled test configuration. Try an incomplete link. Each case should refuse an invalid change, explain the next step and offer a sensible way to request recovery again.

Request two messages close together and open them in reverse order. The product may invalidate the older request or support another explicitly defined rule. Verify that rule rather than assuming which email remains usable. The customer-facing wording should reduce confusion when delayed messages arrive after a newer one.

Also check what requesting recovery does before the password is changed. A customer who did not initiate the request should not unexpectedly lose normal access merely because somebody entered their address. Separate request creation, proof of control and successful credential replacement in the evidence record.

Check mobile and cross-device completion

A customer may request recovery on a laptop and read the message on a phone. Another may open mail in an embedded browser that does not share the website's existing session. Demonstrate these transitions if they fall within the supported journey. Avoid silently requiring the original browser unless that requirement is deliberate and explained.

On the phone, move between the mailbox and the website, rotate the screen where relevant, and return after a brief interruption. Check that the user knows whether they are choosing a password, entering a code or signing in. Similar-looking screens can conceal very different stages.

If the flow uses a one-time code, test the supplied paste and autofill mechanisms and the handling of a replacement code. Do not assume that dividing the code into attractive individual boxes produces an accessible interaction. Ask a reviewer to check focus movement, keyboard operation and the announced state.

Use W3C's form-notification guidance when reviewing instructions and errors. For a wider assessment, the separate website accessibility audit guide explains what evaluation evidence buyers should request. A successful recovery on one phone is not an accessibility verdict for the entire site.

Verify expiry, logout and remembered access

After a successful login, the website relies on a session or equivalent mechanism to recognise later requests. Customers experience this as staying signed in. The launch review should establish when that access ends and what happens to an interrupted task.

Distinguish waiting, closing and signing out

Leave the account idle for the agreed test interval, then perform an action that genuinely needs authentication. Check the result from the server-backed action, not merely the page already visible on screen. Repeat the approved exercise after the absolute session lifetime if the product distinguishes it from idle expiry.

OWASP's session-management guidance emphasises server-enforced expiry and invalidation. Closing the browser is not a dependable substitute for logout because browser restoration can preserve access. The demonstration should therefore test the sign-out control explicitly.

Sign out, return with the Back button, refresh and try a fresh protected action. A previously rendered screen and a newly authorised response are different observations. Ask the developer to explain any cached display of personal information and show that the ended session cannot perform new authenticated operations.

Test the promises attached to a password change

Keep the test account open in a second browser before changing its password. Afterwards, check the agreed policy for existing sessions and remembered devices. Some products provide a choice to sign out elsewhere; others apply a defined invalidation policy. The buyer needs the actual behaviour documented and reviewed for the account's risk.

If “remember me” is offered, demonstrate it separately from ordinary session persistence. Explain its duration, how it is revoked and whether sensitive changes require fresh authentication. A convenient remembered session should not silently become permission for every account change indefinitely.

Set support and evidence boundaries

Loss of the registered mailbox needs a deliberate process. Ask who handles the request, what evidence they may collect, when escalation is required and which changes they are permitted to make. Do not let a support conversation become an undocumented shortcut around the authentication system.

Support staff should never ask customers to disclose passwords or send usable recovery links into a shared project chat. Define an incident reference and a way to investigate the outcome without distributing credentials. OWASP's logging guidance helps distinguish useful security events from sensitive material that should not be recorded.

Separate public search visibility from customer privacy. Public service and product pages need a coherent discovery strategy; private account records need enforced access controls. Google's guidance on controlling shared content distinguishes password protection from search-indexing controls. Hiding a URL from a sitemap does not protect an account.

Keep recovery support responsibilities in the handover record, with the relevant identity and email providers named. When commissioning website development, ask for these operational decisions early enough to affect the build. They are harder to clarify when a customer is already locked out.

Decide what evidence is enough to approve

Before the demonstration, divide the checks into three groups: customer-visible outcomes, developer explanations and independent specialist findings. This prevents an easy-to-observe screen from being used as proof of a protection hidden underneath it. A reset link refusing a second use is observable; the quality of token generation needs a different kind of verification.

For each failed case, describe the consequence in the customer's terms. “Expired link displays an unlabelled error” is useful, but “customer cannot find the route to request another link” explains why it matters. Keep the proposed severity connected to the task and information involved, then let the technical owner explain the cause and remedy.

Record any launch exception explicitly. Include the affected journey, known limitation, temporary customer guidance, responsible owner and condition for closure. An accepted exception is a decision with accountability, not a way to turn a failed test into a pass. Problems that permit unintended account changes need a different response from a minor wording inconsistency.

Repeat relevant checks after the fix in a clean starting state. A reviewer who remains signed in throughout the retest may miss the very problem being investigated. Preserve the case identifier and note the build or release tested so later reviewers can distinguish a new result from an old screenshot.

After launch, keep a small set of account-access regression checks within the agreed maintenance process. Changes to mail templates, domains, identity settings or session configuration can affect a previously working journey. Our guide to website maintenance responsibilities explains how to make ownership and recovery evidence reviewable without assuming a particular WSC support commitment.

When an external identity provider is involved, retain its configuration responsibilities and support route in the handover. Ask which changes your employees may make themselves and which need the developer. Avoid maintaining a second unofficial recovery process simply because the provider's normal behaviour was never explained to customer support.

Run a fictional buyer acceptance exercise

Imagine a Delhi training business whose customers sign in to review course bookings. The example has no connection to a WSC project. Its owner, Meera, wants to approve account access without mistaking a friendly demonstration for complete technical assurance.

She creates two harmless accounts using controlled mailboxes and records the expected recovery and session rules. A developer prepares a shortened expiry in the test environment, clearly marking that it differs from production. The reviewer notes that difference so nobody reports the test setting as the live policy.

First, Meera signs in with saved credentials and confirms the account name. Then she requests recovery from a laptop, opens the message on a phone, chooses a new password and signs in again normally. She checks the old password, the used link and the existing session in the second browser against the agreed outcomes.

Next, the developer demonstrates an expired link and a delayed message arriving after a resend. Meera records one unclear error: the screen refuses the change but gives no route back to recovery. The team fixes the explanation and repeats that case. The record preserves both the initial failure and the retest.

Finally, she reviews an evidence sheet containing case identifier, starting state, expected result, observed result, timestamp, reviewer and unresolved action. Screenshots omit tokens and passwords. A separate technical assessment remains scheduled for the protections that a customer demonstration cannot establish.

Common mistakes that weaken the decision

• Testing only a correct password. Include recovery, interruption and ended access.
• Treating email acceptance as delivery. Observe the message in a controlled recipient mailbox.
• Assuming every new message invalidates older ones. Establish the implemented resend policy.
• Blocking paste for appearances. Check how customers use password managers and codes.
• Approving from screenshots alone. Witness state changes and ordinary subsequent login.
• Calling a hidden page private. Verify enforced access independently of search visibility.
• Recording credentials as evidence. Use redacted records and safe case identifiers.
• Forgetting regression checks. Repeat relevant journeys after identity, email or session changes.

A practical launch checklist

• Account purpose, eligible users and supported authentication methods are documented.
• Test accounts and controlled mailboxes cover the important starting states.
• Normal login works with keyboard operation and supported credential assistance.
• Failure and throttling messages provide the agreed recovery route.
• Password recovery completes through normal subsequent login.
• Used, expired, incomplete and superseded links follow the documented rules.
• Mobile and supported cross-device paths have been witnessed.
• Idle expiry, logout and remembered access have separate evidence.
• Password-change effects on existing sessions have been reviewed.
• Support exceptions have an owner and an approved process.
• Evidence excludes passwords, usable tokens and unnecessary customer information.
• Material failures have owners, retest results and a clear launch decision.

Approve the journey customers will actually need

Account access is a continuing customer service. A useful launch review follows it from ordinary login through recovery and the end of a session, with the awkward states included. The result should be a clear record of what works, what remains uncertain and who owns the unresolved decisions.

Match the depth of technical assessment to the sensitivity of the account. Keep the acceptance demonstration practical, but avoid presenting it as a security certificate. If your project needs a clearer account-access brief, discuss the website requirements with WSC and bring the customer tasks, recovery rules and evidence expectations to that conversation.

Sources

Primary references checked on 28 October 2026; the acceptance exercises above are editorial recommendations.

• OWASP: Authentication
• OWASP: Forgot Password
• OWASP: Session Management
• OWASP: Logging
• W3C: Accessible Authentication (Minimum)
• W3C: Form Notifications
• MDN: Autocomplete
• Google Search Central: Control Shared Content

Photo credits: Mikhail Nilov, mobile use; Mikhail Nilov, device review; Cup of Couple, laptop workspace. Used and adapted under the free Pexels licence. All photographs are illustrative and imply no client relationship or endorsement.