A website can look finished while important customer journeys, search settings or administrative processes remain untested. User acceptance testing gives the business a structured opportunity to confirm that the site meets the agreed requirements before approving launch.
This website testing checklist for Malta businesses focuses on practical acceptance checks that a project owner can organise with a developer. It complements technical quality assurance by testing the site from the perspective of customers, staff and business owners.
1. Start with requirements and acceptance criteria
Testing should trace back to the approved brief, scope and change requests. Create a simple table with one row for each requirement, the expected result, the test result, evidence and the person responsible for resolving any issue.
A requirement such as “contact form” is not testable enough on its own. A useful expected result could state that required fields are enforced, valid submissions reach the correct mailbox, the customer sees a confirmation and the event is recorded in analytics without exposing personal data.
If the requirements are still unclear, use DCP’s website development brief and website development contract checklist to close the gaps before acceptance.
2. Test as real users, not only administrators
Create realistic tasks for the people who will use the website. Ask testers to find a service, submit an enquiry, download a document, complete a purchase, book an appointment or locate contact details without being shown the route.
Include people who were not closely involved in the build. Project teams often know the intended navigation so well that they miss unclear labels or dead ends. Record whether users completed each task, where they hesitated and what information they expected but could not find.
3. Cover representative devices and browsers
Agree which browsers, operating systems and screen sizes the project supports. Prioritise the devices used by the target audience and include real mobile devices where possible. Mozilla’s testing guidance notes that it is not practical to test every combination, so the supported set should reflect the most important environments for the audience.
- Current versions of the agreed desktop browsers
- iPhone and Android mobile browsers
- At least one tablet layout where relevant
- Portrait and landscape orientation
- Touch, mouse and keyboard interaction
- Slower mobile connections and ordinary hardware
Do not limit the review to whether pages load. Check menus, sticky elements, pop-ups, tables, sliders, buttons, forms and embedded tools at each supported size.
Review the main menu, footer, breadcrumbs, calls to action and internal links. Confirm that labels match the destination and that important pages can be reached without relying on site search.
- Page titles, headings and body copy are approved
- Contact details and opening information are current
- Buttons use clear action language
- Images are appropriate, licensed and not distorted
- Downloads open correctly and use the intended version
- There is a useful response to broken or unavailable pages
- Placeholder text and temporary images have been removed
Compare the final site with the approved content inventory. DCP’s website content checklist can help identify missing approvals, assets and ownership.
5. Test every form from start to finish
Submit each form using valid, invalid and incomplete information. Check visible labels, required-field messages, input formats, privacy wording, consent choices, spam controls and the confirmation shown to the user.
Verify the operational result, not only the on-screen message. Confirm that the right recipient receives the submission, the reply-to address works, the record appears in the intended system and authorised staff can find it. Test what happens when an email is delayed or an integration fails.
W3C guidance highlights labels, keyboard access, instructions and effective error handling as important parts of accessible forms. Test whether a person can understand and complete the form using a keyboard alone.
6. Verify purchases, bookings and account journeys
Where applicable, test the complete transaction with approved test methods or a controlled low-value transaction. Include successful and unsuccessful payments, cancelled actions, duplicate clicks, voucher rules, taxes, delivery options, inventory changes, confirmation emails and refunds.
For bookings, check time zones, availability, capacity limits, reminders, cancellations and calendar synchronisation. For user accounts, test registration, verification, sign-in, password reset, profile changes and sign-out.
Use test accounts and suitable non-production data. Do not place real customer information into a test environment unless the necessary controls and lawful basis are in place.
7. Review accessibility with tools and people
Automated checks are useful but incomplete. W3C states that no tool alone can determine whether a site is accessible and that knowledgeable human evaluation is required.
- Navigate interactive elements using only the keyboard
- Confirm that keyboard focus is visible and logical
- Check headings and page landmarks
- Review alternative text according to image purpose
- Test form labels, instructions and errors
- Review colour contrast and content at enlarged text sizes
- Check captions or alternatives for relevant media
Use the more detailed website accessibility checklist for Malta businesses during development, not only at the final approval stage.
8. Test performance on representative pages
Measure the home page, important service or product pages, a content page and any page with complex forms or integrations. Test mobile as well as desktop and review the actual experience while pages load and respond.
Lab tools can identify development issues before launch. Google’s Web Vitals guidance also distinguishes lab measurement from field data, because real-user performance varies with devices, networks and interactions. Record a launch baseline and define how performance will be monitored after real traffic arrives.
- Important content appears promptly
- Buttons and fields respond without frustrating delays
- Content does not unexpectedly shift during loading
- Images use appropriate dimensions and formats
- Third-party scripts do not break core journeys
9. Check search-engine controls before launch
A staging site may intentionally block indexing, but those controls should not accidentally carry into production. Test a representative set of pages and document the expected search status for each.
- Important pages return a successful HTTP status
- Robots settings allow intended crawling and indexing
- Canonical URLs point to the correct production addresses
- Titles and descriptions are unique and approved
- Internal links use final URLs
- The XML sitemap contains the intended indexable URLs
- Structured data reflects visible page content
- Redirects lead to relevant replacements
Google’s technical requirements explain that indexable pages need to be accessible, return a successful status and contain indexable content. Use Search Console’s URL Inspection tool after launch to inspect priority pages. If URLs are changing, follow the safeguards in DCP’s website redesign SEO checklist.
10. Validate analytics and consent behaviour
Confirm that analytics and advertising tools use the correct production accounts. Test important events such as form submissions, phone or email clicks, purchases and bookings. Check that one user action does not create duplicate conversions.
Review consent controls with the organisation’s privacy requirements. Test accept, reject and preference choices, then verify the resulting behaviour rather than relying only on the banner’s appearance. Confirm who owns the accounts and who will monitor data after launch.
11. Test operational and administrative tasks
Ask the staff who will manage the website to perform their real tasks. They might publish a post, edit a page, add a product, change availability, export an enquiry or restore an earlier revision.
- Roles have only the access they need
- Administrative instructions match the live system
- Updates can be made without breaking the layout
- Backups and restoration responsibilities are understood
- Licence, hosting and domain renewals have named owners
- Support requests have a defined channel and priority process
12. Record defects by severity
Log each issue with the page, device, browser, steps to reproduce, expected result, actual result and supporting screenshot or video. Agree a severity system before testing.
- Launch blocker: prevents a critical customer or administrative journey, creates material risk or makes the site unavailable.
- Major: seriously affects an important function but has a temporary workaround.
- Minor: causes limited inconvenience or a presentation issue without blocking the task.
- Future improvement: a useful enhancement that was not part of the accepted scope.
Do not classify a new request as a defect merely because it emerged during testing. Compare it with the approved requirement and use the agreed change-control process where necessary.
13. Require evidence before sign-off
Before approval, confirm that launch blockers and agreed major defects are closed or formally accepted with a corrective plan. Keep the test record, final issue log, approved exceptions and launch decision together.
A practical sign-off states what was tested, which environment and version were reviewed, who approved it, which known issues remain and what post-launch checks will occur. Acceptance should not replace the warranty, support or maintenance terms in the contract.
14. Repeat critical tests immediately after launch
Production can behave differently from staging because domains, caching, email delivery, payment settings, integrations and search controls change. Repeat a concise smoke test as soon as the site is live.
- Open priority pages and verify secure loading
- Submit critical forms and confirm receipt
- Test one complete transaction or booking where applicable
- Check robots, canonicals and redirects
- Confirm analytics and conversion events
- Verify backups and monitoring
- Check that temporary access and test data are removed
Approve a tested website, not an attractive screenshot
Website acceptance should be based on evidence that agreed tasks work for customers and staff. A focused test plan makes defects easier to reproduce, prevents important checks from being forgotten and gives both parties a clearer basis for launch approval.
If you need a website designed, developed and tested around clear business requirements, review DCP’s web design services in Malta or contact Digital Consulting Pros.
Authoritative testing references
