Before approving a website, follow the steps a visitor needs to complete and record whether each step works as expected. A page can look finished while an inquiry fails to reach its destination or an account confirmation never arrives.
Start with the actions your site actually offers. An inquiry site needs a complete inquiry check. A store also needs an agreed purchase test; a site with accounts needs registration checks. Mark a journey that doesn't exist as “Not applicable” and explain why. Use “Not tested” when the function exists but nobody has checked it yet.
Agree who checks what
As the client, check that the offer is accurate, the wording makes sense, and contact details are correct. Walk through the intended customer journeys and, where agreed, confirm that messages reach the designated test inbox. Name the person who can approve launch.
The supplier should check technical behavior, error handling, integrations, and logs in an appropriate test environment. Ask for evidence of the agreed analytics and consent behavior, too. Decide who will carry out each check before testing begins.
For purchases, accounts, and email journeys, arrange test accounts, sandbox payment modes, and test inboxes with the supplier. Use agreed test data. A launch review doesn't need real purchases or messages to customers.
Work through the site as a visitor
| Area | What to check | What to record |
|---|---|---|
| Navigation and links | Open menus, follow the main routes, and check buttons, downloads, and links | Intended destination and actual destination; any broken or misleading link |
| Mobile reading | Read key pages and use menus and forms at the agreed screen sizes | Clipped text, overlapping controls, unwanted horizontal scrolling, or an action you can't complete |
| Forms | Try required fields, malformed entries, and valid test data in the agreed environment | Which inputs are rejected, whether errors explain the correction, and what happens with valid input |
| Confirmations and emails | Complete an approved test journey and check the on-screen result and designated inbox | Whether the confirmation matches the result and the expected message arrives |
| Purchases or accounts | Follow only the journeys included in the project, using approved test arrangements | Expected order or account state and the actual result, with supplier evidence where needed |
| Analytics and consent | Ask the supplier to demonstrate the agreed behavior for relevant choices | What was checked, the expected behavior, and supporting evidence |
| Content and handover | Check service or product details, contact information, and agreed access | Corrections needed, access received, and any platform or license conditions affecting handover |
Check the main navigation and controls with a keyboard and try enlarging the page. These can reveal barriers, but preliminary checks can miss significant accessibility problems. They don't establish accessibility conformance. W3C's Easy Checks explains that boundary.
Functional testing also doesn't provide privacy approval, security assurance, or legal certification. Confirm any separately required review with the relevant specialist. A supplier demonstrating consent behavior is evidence of that behavior, not a legal conclusion.
A small check, with a precise result
On September 15, 2026, a browser check examined the email field on the Croatian contact page. It used Chromium 148 on a computer, with a page area of 390 × 844 pixels. This was a mobile-sized view, without testing on a physical phone.
The check inspected browser field validity without pressing Submit:
| Email input | Expected result | Actual result |
|---|---|---|
| Empty | A required field is invalid | Invalid; the browser reported a missing value |
not-an-email |
Malformed email is invalid | Invalid; the browser reported a type mismatch |
reader@example.com |
The field accepts valid email syntax | Valid at field level |
The values were cleared afterward without submitting the form. Accepted email syntax doesn't prove the address exists or that sending works. This check did not test the server's handling of a submission or delivery to an inbox.
An accurate record for the malformed input would read: “Email format check passed at browser-field level; delivery not tested.” Its owner is the reviewer. The complete inquiry journey remains untested. That distinction prevents a narrow successful check from becoming an unsupported launch approval.
Turn findings into a release decision
Use the editable acceptance record to capture the project URL, test date, browser or device, and applicable journeys. For each check, enter the steps, expected result, actual result, evidence or notes, owner, and status. Keep screenshots and notes specific to the issue, using test data.
If a result differs from what was agreed, record the difference and assign someone to resolve it. A message saying “fixed” is a reason to retest. Repeat the steps, record the new result, and update the status only when the evidence supports it.
Before approving launch, review unresolved issues and untested work with the supplier. Record whether each issue blocks release or is explicitly accepted for later correction, with an owner and agreed next action. An empty failure list isn't evidence that all required checks passed.
Mischka Studio's web design service includes checks of mobile reading, navigation, forms, and performance before launch. Agree the project-specific review and access handover in advance, including relevant platform and license terms, so the final approval has a clear basis.
Source note: Mischka Studio's bilingual web design service records and contact form, checked September 15, 2026; the dated browser demonstration described above; and W3C Easy Checks, accessed September 15, 2026. The demonstration covers email-field validity only.
