Website Testing Checklist

A website testing checklist supports systematic verification; it does not promise to find every defect. Its value is that the team understands the scope, expected results, and remaining risk. One list cannot serve a news site, banking portal, and internal administration panel equally well.

Adapt the items to the product and release before a run. An order form change calls for a different depth of testing than a footer text correction. The checks below provide a foundation: select the applicable items and add risks specific to the change.

Prepare the testing context

Record the build, environment, changed areas, roles, test data, and supported browsers. Identify the critical flow: what outcome brings users to the site, and which failure would be especially costly?

Each item needs a result and evidence. Use "passed," "defect," "blocked," "not tested," and "not applicable" statuses with explanations. A skipped test cannot count as passed. Prepare a safe environment and data for test payments, emails, and deletion.

→Open the home page and key pages directly by URL: the correct content loads and required resources work.
→Refresh a nested page: the server and client preserve the correct route without an unexpected error.
→Navigate back and forward: the UI restores consistent state and does not accidentally repeat an action.
→Open a nonexistent address: a clear error page provides a way to continue, and the HTTP response matches the resource's purpose.
→Check menus, internal links, and external service navigation: there are no dead ends, incorrect domains, or redirect loops.

Account for both clean and existing sessions. A newly opened site and a long-lived tab may receive different asset versions and state.

Check the main business scenario

Follow the entire flow from entry point to outcome, then verify that the result was actually saved. A "success" message alone does not confirm a data change.

For a store, this means finding a product, using the cart, checking out, and viewing the order. For a knowledge base, it means finding and reading an article, following related content, and obtaining a correct URL to share. Use realistic roles and data: an administrator may bypass restrictions that ordinary users encounter.

Check forms and data

→Empty, ordinary, and boundary values are handled according to the contract; errors help users correct their input.
→The button and Enter trigger consistent submission, and repeated clicks do not duplicate an operation.
→After server rejection, valid values remain and there is a clear way to retry.
→Long text, Cyrillic characters, different locales, and date formats do not corrupt data.
→File uploads and downloads meet type, size, filename, and access requirements.

Compare entered data, the request, the response, and the state retrieved afterward. This chain helps identify precision loss or unnoticed normalization.

Confirm that sign-in, sign-out, session expiry, and reauthentication follow product policy. Test a protected URL without signing in and an operation under a role without the necessary permission.

Using prepared accounts, check access to another user's test object through both the UI and API. Hiding a button does not replace server-side access control. After switching users, the app must not show the previous account's data from its own state or an incorrectly used cache.

Check errors, network behavior, and recovery

Slow the network, interrupt a request, reproduce an intended server error, and return an empty response. Expect a clear state, a loading indicator that finishes, and a defined way to continue.

An uncertain outcome is especially important: the server may have saved an order while the client did not receive the response. Retrying must not silently create a second order. Check server consistency and the intended duplicate protection. Use Console and Network for diagnosis, but judge the outcome by product behavior and data.

Check presentation and accessibility

Select browsers and sizes from the support matrix. Complete the critical action in a narrow window, with long content, and at increased zoom. Fixed panels and the keyboard must not cover required actions.

Follow the flow using the keyboard; check visible focus, field labels, understandable errors, and accessible button names. Use a screen reader where needed. Automated checks provide additional signals, but do not establish that every process is accessible.

Check public visibility and release settings

For a public site, check title, description, canonical, robots rules, sitemap, and expected redirects. For a private service, correct access restrictions matter more. Avoid applying search indexing requirements to private account areas.

Check production configuration: API domains, links, assets, and the absence of test stubs or diagnostic secrets. After deployment, perform a short smoke test using authorized data. Confine load and destructive testing to the designated environment and agreed scope established beforehand.

Practical example: a checkout release

Suppose the address form and delivery calculation changed. Prioritize completing checkout, address boundaries, changing delivery methods, and retrying after a timeout.

1.Create a test order with an ordinary address. Expect one record containing the correct address, amount, and delivery method.
2.Enter a long address on a phone and correct an error. Messages and the button should remain accessible with the keyboard open.
3.Change the address before calculation finishes. The latest selection should apply rather than a delayed response.
4.Repeat confirmation after a simulated response failure. Expect a consistent status without a duplicate.
5.Check order viewing under another test role. Access rules should be enforced.

Select remaining items according to affected dependencies and defect history, rather than merely trying to complete the entire list.

Finishing the run

In the report, link defects to checklist items and state the environments covered, blockers, and untested areas. Distinguish "no known defects were found" from "there is no risk": testing cannot prove the latter.

Common mistakes include using the same depth for every release, omitting expected results, and marking blocked checks green. A good checklist supports a release decision based on evidence and stated limitations.

An evidence-based web release sheet

Use a concrete task such as submitting a fictional contact form. Agree field rules, success behavior and supported browsers before testing. The following rows specify observations; they are a compact release worksheet, not a complete security or accessibility audit. Record actual results separately from expectations.

plain text

Area	Action	Expected observation	Evidence to collect
Function	Submit one valid form	One accepted submission and clear confirmation	Request ID + UI
Validation	Submit missing required email	Specific error; no success; invalid request handled per contract	UI + request log
Keyboard	Complete task using Tab/Shift+Tab/Enter	Visible focus; reachable controls; no keyboard trap	Video
Labels	Inspect input accessible names	Name describes purpose; error associated with its field	Accessibility tree
Responsive	Use agreed narrow/wide viewports	No clipped controls; content usable	Viewport + screenshot
SEO	Fetch public page HTML	Correct language, title, canonical and index policy	Headers + HTML excerpt
Network	Interrupt before/after submit	No false success; safe recovery without duplicate submission	Network trace
Data	Read back accepted submission	Persisted values match input and access policy	Sanitized record evidence

Example observation is hypothetical: if the button shows “Sent” while the request returns a server error, record the status, timestamp and UI state; do not claim the message was stored. Conversely, a timeout does not prove the server rejected the write. Reconcile the result before a retry.

QA Hub tools can assist with specific evidence: URL parser explains query parameters, JSON formatter makes response structure readable, JSON diff compares expected and actual payloads, and HTTP codes provides a reference. They do not decide whether a product requirement is satisfied. Finish with known failures, untested scope, owners and a release-risk decision.