Skip to contentTalk to us
العربيةLog inStart free
Website testing

Your site works for you. Make sure it works for your customers

It does not matter where your site was built or who built it. Add its address, tell the QA engineer in your own words what matters, and it opens the site in a real browser and walks it the way a customer would: signing up, filling in forms, finishing an order. Whatever breaks reaches you with steps and a screenshot, not a vague impression.

Start freeHow it works
Add the address and startA real browser, not a simulationPart of the paid plans
Why now

The bug you never see is the one that costs you

1

Customers do not report, they leave

A button that does nothing or a form that rejects a phone number, and the customer does not write to you: they close the page and go elsewhere. You see fewer orders and never learn why.

2

You only test what you already know

You open your site on your device, with your account, along the route you know by heart. A new customer arrives on a phone, with no account, and taps what you never thought of.

3

Every update can break something else

The developer fixed the product page and the cart stopped working. Re-checking the whole site by hand after every change is a job nobody does consistently.

1Getting started

Add your site’s address and start

Nothing to set up on your site and no waiting: you enter the site’s address and it is ready to test, and by adding it you confirm it is yours or that you are allowed to test it. Then you set the rules: is this a staging copy or the live site, and what must never be touched. Testing stays inside your site’s address, and tests that change data, such as creating an order or an account, stay off unless you allow them.

  • The address is enough, nothing to set up on your site
  • Read-only is the default
  • An optional test account, stored encrypted
2Evidence

A report the owner understands and the developer can act on

Every bug reaches you as one clear card: its impact on your business, its severity, the steps that reproduce it, what was expected against what actually happened, a screenshot from the moment it failed, and a likely cause when the evidence supports one. Passwords are masked in screenshots. Fanann does not change your site’s code: you or your developer make the fix, then a retest proves it worked.

  • Steps that reproduce it every time
  • Expected vs actual, with a screenshot
  • Not closed until the retest passes
3The decision

Ready or not ready? One clear answer

At the end of a run you are not handed a long list and left with it. You get a verdict: ready, not ready, or inconclusive when too few tests completed. With it comes exactly what is blocking launch, and what the run did not cover, so a pass is never read as a guarantee for things that were not tested.

  • Launch-blocking bugs at the top
  • Tells a site bug from a test that could not run
  • The limits of coverage stated plainly
Examples

Say it in your words; the QA engineer turns it into tests

You do not need to know what the tests are called. Describe what worries you as you would to a new hire.

An online store before a sale season

It walks the whole path: finding a product, adding it to the cart, changing the quantity, entering an address, up to the payment page, at desktop size and at phone size.

Test buying from the first search to the payment page and make sure everything is clear on a phone. Do not complete any real payment.

A clinic site with a booking form

It tries the form with correct, missing and wrong data: a short phone number, a past date, an empty field. It checks that error messages make sense and that the booking is confirmed.

Try the booking form every way a patient might get it wrong and tell me where it breaks or confuses.

A customer portal with sign-in

With the test account you provide it signs in and browses the private pages, checks that a visitor who is not signed in cannot reach them, and that signing out really works.

Sign in with the test account and make sure the customer pages do not open for someone who is not signed in.
The steps

How to test your existing website in four steps

From adding the site to retesting after the fix.

  1. 1

    Add your site

    In “QA Engineer” choose “Test an external website”, enter its address and say whether it is a staging copy or the live site. By adding it you confirm it is yours or that you are allowed to test it, and it is ready straight away.

  2. 2

    Set the rules

    May it create test data? What must never change? If there are pages behind a sign-in, add a test account.

  3. 3

    Say what to test and review the plan

    Write your request in your own words or pick a ready check. The QA engineer explores the site and proposes test cases; switch off what you do not want before running.

  4. 4

    Run, read the report, then retest

    Watch the run live if you like, then read the verdict and the bugs. Once your developer has fixed what turned up, press “Retest” to prove the fix.

Plainly: what you should know

No code changesFanann does not change the code of external sites: it gives you the steps and a likely cause, and the fix is yours or your developer’s.
Websites and web appsTesting runs in a real browser, including at phone size. Mobile apps installed from the app stores are out of scope.
Not load or securityIt does not measure how the site holds up under thousands of visitors, and it is not a security audit. It checks that the site works as it should for a real user.
Only with your permissionBy adding the site you confirm it is yours or that you are allowed to test it. No data is created or changed on your site unless you switch that on yourself.
FAQ

Questions people ask

How do I test my website before launch without a testing team?
Add your site’s address to Fanann’s QA engineer, then write what you want to be sure of in your own words. The QA engineer proposes a test plan you review, runs it in a real browser, and hands you a clear verdict and a list of bugs with their evidence.
Does website testing work on a site that was not built with Fanann?
Yes. It works with any website or web app, however it was built and whoever built it. Add its address and start.
What do I need to start testing my website?
Just the site’s address. Nothing to set up on the site itself and no waiting: you add the address and it is ready to test, and by adding it you confirm it is yours or that you are allowed to test it. Testing stays inside your site’s address, and internal or private addresses are refused.
Will testing change data on my live website?
No, unless you allow it. The default is read-only, and tests that would create an order or an account are skipped and listed in the report as needing your permission. Where you have a staging copy, that is the better place to run them.
Does Fanann fix the bugs it finds on my website?
On external sites, no: Fanann does not own your site’s code and does not change it. It gives you the steps to reproduce and a likely cause for your developer to fix, then you retest to be sure. For apps built with Fanann, you can ask Fanann to fix them.
Does it test the website on mobile?
It tests your site at phone screen size inside a real browser, which catches cut-off buttons, forms that cannot be filled in and menus that will not open. It does not test mobile apps installed on devices.
Is website testing in Fanann free?
Signing up to Fanann is free, and the QA engineer is part of the paid plans. Testing external websites, and exporting or sharing reports, depend on your plan.
QA Engineer

What else can the QA engineer test for you?

QA Engineer

The main page: an AI QA engineer that plans tests, runs them in a real browser, documents every bug with evidence and tells you whether your app is ready to launch.

Meet the QA engineer

API testing

Upload the API description file and the QA engineer checks that every request returns what it should: status, fields, permissions and error messages.

See the details

Regression testing

Every test case is saved and re-run. After any change you know in minutes whether what worked still works, and when it broke.

See the details

Bug tracking

Every bug is a card with impact, steps, expected vs actual and a screenshot, and it stays open until a retest proves it fixed.

See the details

Test before launch

Built your app with Fanann? Test it from the publish window itself, ask Fanann to fix what turns up, then publish knowing where it stands.

See the details

For restaurants & booking

Two guests, one table, 7 pm: how the QA engineer finds the double booking before your guests do.

See the details

Guides to read before you test

What is software testing?

An explanation for business owners, without jargon: what gets tested, the kinds of testing that actually matter to you, and when manual testing is enough and when it is not.

Read the guide

Website testing checklist

A practical list to go through before you announce your site: sign-up, forms, checkout, mobile, Arabic, messages and what comes after launch.

Read the guide

How to write a bug report

A ready template and examples: a clear title, steps that reproduce the bug, expected vs actual, evidence, and how to set severity without exaggerating.

Read the guide
Website testing checklistHow to write a bug reportTrust center: how we protect your dataPlans and pricing
From the blog

Guides to testing and AI QA

All Testing & AI QA guides
PASSPASSBUGPASSPASSWhat is an AI QA agent? How it tests your site like a careful person9 min readAn AI product team in one place: plan, build and test without hiring11 min readPASSPASSBUGPASSPASSAI QA agent or a human tester: who should test what?9 min read

Know how your site is doing before your customers do.

Add your site’s address, tell the QA engineer what matters and get a clear verdict with bugs backed by evidence. The QA engineer is part of the paid plans, and signing up is free.