The website testing checklist to run before you launch

How do you run the check? Eight steps, in order

1. 1
   Write down the flows that make you money

   Pick three to five flows where a failure costs you a customer: sign-up, finding a product or a time slot, adding to cart or booking, paying, and the confirmation message. These are tested first and with the most care.

2. 2
   Prepare test accounts and a test payment method

   Create a new customer account, a staff account and an admin account, using phone numbers and emails you own. Switch your payment gateway to test mode and use its test cards. Never test with real customers’ cards.

3. 3
   Start on a phone

   Most of your visitors will arrive on a phone, so make it the first test device, not the last. Open the site from a link the way a customer would: from an ad, a message or a search result.

4. 4
   Walk each flow as a new customer

   No saved account and no inside knowledge. Finish the flow from the first page to the confirmation message without skipping a step, and note every moment you hesitated: hesitation is a clarity bug even when nothing breaks.

5. 5
   Try to break every form

   Leave it empty, type the wrong format, paste a very long text and press the submit button twice. Real customers will do all of that by accident in the first week.

6. 6
   Write down every bug properly

   For each bug: where it happened, the steps that reproduce it, what you expected, what actually happened, and a screenshot. A bug without steps does not get fixed; it comes back as “how do I reproduce it?”.

7. 7
   Fix, then repeat the same steps

   Do not call a bug done because someone said “done”. Repeat the written steps exactly and confirm the result is now what you expected, then quickly walk the whole flow again, because a fix can break something next to it.

8. 8
   Decide: ready or not ready

   The decision does not need a bug-free site; it needs healthy money flows. Any bug that blocks buying or booking, or exposes a customer’s data, stops the launch. Everything else is ranked and fixed afterwards.

The lists below spell out what to try at each step. You do not have to finish them in one sitting: start with the critical flows list, since it protects your sales, then work through the rest one section at a time.

Critical flows: from the first visit to the confirmation

This list is the heart of the check. Run it at least twice: once as a new customer, and once as a returning customer with an account and a past order.

• The home page opens from a direct link and from a short link in a message, and its main button takes you to what you sell.
• Sign-up completes with a new phone number or email, the verification code arrives and is accepted, and resending it works.
• Search finds the product or service by its Arabic and English name, and with a small typo, and filters really change the results.
• The product or service page shows the price, availability and options (size, colour, duration) exactly as they are in your admin panel.
• Adding to the cart works, changing the quantity and removing items update the total at once, and the cart survives a page refresh.
• For bookings: a slot that was booked disappears from what is available, and two people cannot book the same slot or the same table.
• Checkout completes as a guest (if you allow it) and as a signed-in customer, with a new delivery address and with a saved one.
• The confirmation page shows the order or booking number and the right details, and the order appears in the customer’s account and in the admin panel with the same status.
• Cancelling or changing from the customer’s account works the way your policy promises, and shows up in the admin panel.

If your site takes bookings, double booking deserves a test of its own. The QA engineer for restaurants and booking page walks through a full example: two guests, one table, 7 pm.

Forms and input validation

A good form accepts what people actually type and rejects mistakes with a message that says what to fix. Try these on every form: sign-up, address, contact, booking.

• Submit the form empty: every required field is clearly marked, and the message sits next to the field, not only at the top of the page.
• Type an email without @ and a phone number that is too short: the error is explained in the customer’s language, and what they typed in the other fields is not wiped.
• Type the phone number in Arabic-Indic digits ٠١٢٣٤٥٦٧٨٩ and in 0123456789: both are accepted and saved in one format.
• Try the number with and without the country code, and with spaces and dashes: either it is accepted, or the message shows the required format with an example.
• Type the name in Arabic and then in English, with diacritics or hamzas: it is saved and displayed as typed, in the account and on the invoice.
• Paste a very long text into the notes field: the layout does not break, and if there is a limit, a counter or a message tells you so.
• Press the submit button twice quickly: one order is created, not two, and the button is disabled while sending.
• Go back with the back button after submitting, then forward: the form is not sent a second time behind your back.
• Date and time fields do not accept a time in the past or outside your opening hours.
• Upload an image larger than allowed or a file in an unsupported format: it is refused with a clear message, not an error page.

Sign-in and permissions

The most serious bugs live here, because they touch your customers’ data. The idea is simple: each person sees only what is theirs, however hard they try.

• A wrong password is refused with a message that does not reveal whether the account exists.
• “Forgot password” sends a link or a code that works once and expires after a while, and the old password stops working after the change.
• After signing out, the back button does not show account pages.
• Leave the page open for a long time and then continue: if the session expired you are asked to sign in and returned to where you were, without losing your cart.
• Signed in as one customer, change the order number in the URL to another number: another customer’s order does not open.
• Open an admin page URL as an ordinary customer, or signed out: you are refused and sent to the sign-in page.
• A staff account sees only what you gave it: no cost prices, no reports and no deleting orders unless you granted that.
• Disable a staff account from the admin panel: they are signed out of their open session and cannot sign in again.
• Sign up with a phone number or email that is already registered: the message points you to sign in and no duplicate account is created.

Payments and orders

Test payments in the test mode your payment gateway provides, with its test cards, then run one real transaction for a small amount with your own card before you announce. Local payment methods are covered on the payments page.

• A successful payment: the order becomes “paid” in the customer’s account and in the admin panel, and the amount matches what was shown before paying.
• A declined card: a message people can understand appears, the cart stays as it was, and the customer can try another method.
• Press back or close the page in the middle of paying: no “paid” order exists without a payment, and no money is taken without an order.
• Refresh the confirmation page: the amount is not charged again and the order is not duplicated.
• The total is right to the last decimal: item prices, discount, delivery and VAT, with the same rounding in the cart, on the invoice and in the confirmation message.
• Discount codes: a valid one works, an expired or already-used one is refused, and none can push the total below zero.
• The invoice arrives and carries your business details, your tax number where required, and the right order details.
• Cash on delivery (if you offer it): the order is recorded with a clear status that sets it apart from paid orders.
• Refunds: cancel a paid order from the admin panel and check that the status changes and the customer is told.
• Stock goes down after an order, and the last item is not sold to two customers.

Phone layout

Test on a real phone with a small screen if you can, not only in a narrowed browser window. The smallest common width is about 360 pixels; what works there works on anything larger.

• No horizontal scrolling on any page, and no text or button cut off at the edge of the screen.
• Buttons and links are easy to hit with a thumb and not crammed together: you do not tap “delete” when you meant “edit”.
• When the keyboard opens, the field you are typing in and the continue button stay visible.
• The phone field opens the number pad, and the email field opens a keyboard with @.
• The menu opens and closes, and everything in it leads to its page.
• Pop-ups and the cookie notice are easy to dismiss and do not cover the buy button.
• Try a weak connection: the page shows that it is loading, and tapping repeatedly while you wait does not duplicate the order.
• Images are sharp and not stretched, and long tables turn into cards or scroll inside their own frame.
• Rotate the phone to landscape on the payment page: what you typed is not lost.

Arabic and right-to-left

An Arabic site is more than translated text. Direction, digits, dates and currency all need checking, especially when the site is bilingual.

• The whole page runs right to left: menus, arrows, progress bars and the back icon.
• Mixed text is intact: an English product name inside an Arabic sentence, an order number, an email address and a link all read in the right order.
• Phone numbers and amounts do not have their digits flipped, and the + sign or the currency symbol does not drift away from them.
• The currency is written one way everywhere, and the decimal separator is the same in the cart and on the invoice.
• Dates and times make sense to your customer: day before month, morning and evening clearly marked, and the Hijri calendar correct if you show it.
• No Arabic label or heading is cut off with an ellipsis, and no English text is left behind on an Arabic page.
• Switching language keeps you on the same page and does not empty the cart.
• Search is forgiving about hamzas, taa marbuta and alif maqsura: the same word typed with or without them returns the same results.
• Error and confirmation messages are written in natural Arabic, not word-for-word translation.

Messages and notifications

The confirmation message is part of the product: it is what stays with the customer after they close the site. Place a test order with your own number and email and read everything that arrives, word by word.

• The confirmation arrives within a reasonable time, on the channel you promised: email, SMS or WhatsApp.
• It has the right name, order number, amount and time slot or address, with no empty fields and no odd placeholders where the name should be.
• Every link in the message opens the right page on a phone, and the order tracking link works without signing in, if that is what you intend.
• The message is in the language the customer chose on the site.
• The sender name and address clearly belong to your business, and the message does not land in spam in your test account.
• The verification code arrives, asking for a new code cancels the old one, and one tap does not send several codes.
• You or your staff are notified of every new order or booking, and of every cancellation.
• Appointment reminders arrive at the right time and stop if the booking is cancelled.

Error and empty states

Every site fails sometimes. What separates a professional site from the rest is what the customer sees at that moment: a message that explains and suggests, or a blank page.

• Open a link that does not exist: a “not found” page appears in your site’s design with a link to the home page or search.
• Search for something that is not there: “no results” appears with a suggestion, not an empty page.
• A product that ran out or a slot that filled up: this is clear before payment, not after.
• A new account with no orders: the “my orders” page explains and invites a first order.
• Cut the connection and press a button: a “check your connection” message appears and what you typed stays.
• If something fails on the server, the customer sees a human message such as “something went wrong, try again shortly”, not technical text or codes.
• Open the link of a cancelled order or a deleted product: a clear status appears, not an error.
• Missing images or broken links on the main pages and in the footer: go through all of them once.

How to decide: what stops the launch and what can wait?

After the check you will have a list of bugs, and that is normal. Do not try to fix all of them before launch, and do not ignore all of them either. Rank them by severity: what does the customer, or your business, lose if the bug stays?

Severity is not priority: severity says how much the bug hurts, priority says when you fix it. That, and a ready template, is covered in how to write a bug report.

After launch: the checking does not stop

The most painful bugs are not the day-one bugs; they are the things that quietly break after a small change in week five. Make checking a short, repeated habit rather than a one-off event.

• After every change, even “just a text change”, re-run the critical flows list before you tell your customers.
• Pick one day a week for a short test run: sign-up, an order or booking, a test payment and the confirmation message.
• Keep your steps written down. Written steps are repeated as they are; memory forgets the awkward cases.
• Every bug a customer reports becomes a new line in your list, so it cannot come back unnoticed.
• Watch real errors after launch: abandoned orders, failed payments and whatever faults your site records.
• Before big seasons and campaigns, run the whole check again, not only the flows.
• A bug that was fixed and came back is treated as more severe: it means something in how changes are made needs a second look.

Re-testing after every change has a name: regression testing. The plain-language explanation is in what is software testing?, and how to automate it is on the regression testing page.

How does Fanann’s QA engineer run this list for you?

You can run the list above by hand, and we suggest you do so at least once to get to know your site. Repeating it after every change is what wears people out until they stop. That is where the QA engineer comes in: you assign the work in plain words, such as “test the booking flow on a phone and make sure a slot cannot be booked twice”, and it handles the rest.

• It proposes a plan you review before anything runs: test cases ranked by priority, with a warning on anything that may create data.
• It runs in a real browser, including at phone size, and checks your API if you upload its description file. See API testing.
• It documents every bug with evidence: a screenshot, the steps that reproduce it and expected vs actual, in the bug tracker.
• A bug counts as fixed only after a passing retest, and the test cases are saved so they can be re-run after every change.
• It gives you a clear verdict: ready, not ready or inconclusive, together with what the run did not cover.

It works with apps built with Fanann, where it can hand a bug to Fanann’s builder to fix and then retest (test before launch), and with external websites once you add their address. Tests that change data stay off unless you allow them. The QA engineer is part of the paid plans, and scheduled runs come with the higher plans.

Frequently asked questions