New · Fanann QA

Hire a QA engineer that tests your app before your customers do

Tell it in plain words what to test. It plans the tests, runs them in a real browser against your app or website, documents every bug with a screenshot and clear steps, and follows it until a retest proves it fixed. Then it tells you straight: ready to launch, or not.

Start free See the six steps

Tests in a real browserEvery bug with its evidencePart of the paid plans

rose-cafe.example/bookingView only

Rose CaféGuest oneGuest two

Book your table

TodayTomorrowThursday

6:007:007:008:00

Table 4 · 2 guests

Confirm booking

Booked · Table 4 · 7:00 pm

Table taken · pick another time

CriticalScreenshot · 3 stepsOne table booked twiceSteps to reproduce attachedFix verified

Test run · table bookingIllustrative example

Open the booking page
Guest one books table 4 at 7:00 pm
Guest two asks for the same table
Expected: the second booking is refused

Testing…1 bug · not readyRetested · passed

Illustrative example: “Rose Café” is not a customer; the scene shows how it works.

A plan you review first

Nothing runs before you see what will be tested and what may create data.

A real browser

It opens your pages, clicks and types the way a customer would, and you can watch it work.

Every bug with its evidence

A screenshot, the steps, and expected versus actual. Not an opinion without proof.

A proven fix

A bug is not closed by the word “done” but by a passing retest.

How it works

From “test my app” to “fix verified” in six steps

Discover, plan, test, decide, fix, retest. You review and approve; the engineer does the work and documents it.

1Discover
It gets to know your app before judging it
It browses the pages, forms and flows inside the scope you allow, and reads the API description file if there is one. If your app was built with Fanann, it already knows its pages and tables from the project itself. What cannot be known from the outside is labelled as inferred, never stated as fact.
- Stays inside the scope you set
- Separates what it observed from what it inferred
- Asks you only when it cannot continue safely
What I found in your app4 pages · 3 formsIllustrative example
Booking pageForm · 4 fieldsObserved
Sign-inPhone number and codeObserved
Menu12 items · searchObserved
My bookingsCancel and changeObserved
What I infer is labelled as inferred, not as fact.
2Plan
A plan you understand, and edit before anything runs
It proposes test cases grouped by flow, each with its priority and where it came from: you asked for it, it inferred it, or it observed it in the app. You see which cases create data, plus the estimated time and cost, then choose “Review & run” or “Quick test”.
- Switch off any case you do not want
- The estimate appears before you spend anything
- Cases are saved so they can be run again
Proposed test planReview it before anything runsIllustrative example
No double bookingHigh priority · creates test bookingsYou asked
Booking in the pastMediumInferred
Party larger than the tableMediumObserved
3 casesabout 4 minutesCost shown before you run
Review & runQuick test
3Test
It runs in a real browser while you watch
It opens pages, clicks, types and waits for the result the way your customer would, step by step, with a clean session for each case. You follow the current step and a view-only live picture. If sign-in fails, what depends on it is not counted as failed; it is marked blocked, with the reason.
- Plain results: passed, failed, blocked, inconclusive, flaky
- Phone-size layout is part of the test
- Stops at the run’s limit and tells you what was actually done
rose-cafe.example/bookingView only
Rose CaféGuest oneGuest two
Book your table
TodayTomorrowThursday
6:007:007:008:00
Table 4 · 2 guests
Confirm booking
Booked · Table 4 · 7:00 pm
Booked · Table 4 · 7:00 pm
Table taken · pick another time
CriticalScreenshot · 3 stepsOne table booked twiceSteps to reproduce attachedFix verified
Test run · table bookingIllustrative example
Open the booking page
Guest one books table 4 at 7:00 pm
Guest two asks for the same table
Expected: the second booking is refused
Testing…1 bug · not readyRetested · passed
4Decide
A straight verdict: ready to launch or not
After the run it separates a bug in your app from a problem with the test or the environment, and groups failures with one cause into one bug. Then it writes a report for the person who decides: what threatens the business, which flows are affected, and what to do next.
- Ready, not ready, or inconclusive
- The business impact of each bug comes first
- What was not covered is always stated
Is the app ready to launch?Run reportIllustrative example
Not readyReady to launch
Not readyInconclusiveReady
Open critical bug: double bookingNo open critical bugs
Not covered: paying with a real cardThe report always states its limits
5Fix
From report to fix, without explaining it twice
If the app was built with Fanann, one button hands the bug to Fanann’s builder with the steps and the diagnosis, and the fix is built on the preview. If it is an external site, you get the steps and the likely cause to hand to your developer. We do not change the code of a site we did not build.
- “Ask Fanann to fix it” for Fanann apps
- For external sites: steps and a diagnosis for your developer
- A likely cause is given only when the evidence supports it
CriticalOne table booked twiceAn app built with Fanann
Ask Fanann to fix it
Builder task: stop the same table being booked twiceFrom the steps and diagnosis in the report
The fix is built on the preview
The retest starts by itself
An external site? You get the steps and the likely cause to hand to your developer. We do not change your site’s code.
6Retest
“Done” is not enough. Proof is
After the fix the engineer re-runs the same cases that failed, plus the ones related to them. If they all pass, the bug is stamped “Fix verified”; if not, it goes back to open. A bug that returns after being fixed is marked regressed, and its full history is kept.
- “Fix verified” only after the retest passes
- Clicking “done” only moves it to ready for retest
- Scheduled runs on higher plans
One table booked twiceBug history
NewFound in a test run
ConfirmedReproduced a second time
Being fixedWith Fanann or your developer
Ready for retest“Done” alone is not enough
Verified fixedThe same cases passed
Retest: 3 of 3 cases passedFix verified
Illustrative example

No setup

Hire it, don’t configure it

Testing tools ask you to become a tester. The QA engineer only asks you to explain what matters to you.

What you do not need

Writing test scripts and maintaining them every time the interface changes
Learning testing languages and their jargon
Setting up servers and environments to run tests
Reading technical logs to work out what failed

Our test cases are readable steps, not code: you read and edit them like a to-do list.

What you say to it

Examples of tasks you write in your own words

“Test the restaurant booking system and make sure two guests cannot book the same table at the same time.”
“Sign in as a customer and try to open another customer’s order.”
“Test checkout from the cart to the confirmation page at phone size.”

Or start from a ready taskQuick health checkFull reviewSign-in & permissionsBooking & checkout flowAPI reviewPhone layoutRegression suite

The bug report

A bug report you can hand to your developer as it is

Not “something is wrong with the site”. Every bug comes with what the person fixing it needs, and what you need to decide whether it delays the launch.

Title and impact firstWhat broke and what it means for the business, in two lines a non-technical reader understands.
Severity is one thing, priority anotherCritical, high, medium or low, with the confidence in the diagnosis kept separate.
Steps that reproduce itNumbered and from a clean start, so your developer reproduces it on the first try.
Expected versus actualSide by side with no interpretation: what should have happened and what did.
The evidence is attachedA screenshot taken at the failure, with passwords and secret values masked.

Bug tracking to a verified fix Guide: how to write a bug report

CriticalOne table booked twiceBookings · staging copyConfirmed

Impact: two parties arrive for the same table at the same time.

Screenshot at the failure: two confirmations for table 4 at 7:00 pm

Steps to reproduce

Book table 4 for today at 7:00 pm as guest one.
Sign in as guest two.
Book the same table at the same time.

ExpectedThe second booking is refused with a clear message.

ActualBoth bookings were accepted and confirmed.

Test case: no double bookingIllustrative example

The launch decision

Only three verdicts, all of them straight

The verdict is computed from the run’s results by fixed rules, not from an impression. The final call stays yours.

Ready

The core cases passed

No open bug has the severity that blocks a launch. “Ready” does not mean “bug-free”; it means what was tested passed.

Not ready

A blocking bug appeared in this run

You see it at the top of the report with its business impact and its steps, before any other detail.

Inconclusive

Too little was tested to decide

Many cases were blocked or skipped, or the run was small. We do not guess: we tell you what is missing to decide.

Follow the trend, not one snapshot

Each run is compared with the one before: what is new, what was fixed, what regressed. Over time you see the pass rate climb, or get a warning when it drops. On plans that include export you can download the report or share it through a read-only link.

Regression testing

What it tests

A Fanann app, your existing site, or your API

One engineer and one engine: Fanann’s QA engine. You do not have to move your site to Fanann to test it.

An app you built with Fanann

Test it from the publish window, hand the bug to the builder, and the cases re-run by themselves after the fix.

Test before launch

Your existing website or web app

Add its address and start, set what is and is not allowed, and get reports to hand to your developer.

Website testing

Your API

Upload the API description file and the engineer checks statuses, fields, permissions and error messages.

API testing

Who is the QA engineer for?

The business owner

You want to know booking and checkout work before you announce the opening.

The non-technical founder

You are taking delivery from a developer or an agency and want proof, not a promise.

Agencies and freelancers

Hand the client a quality report with the project, and re-test before every delivery.

Small product teams

No full-time tester? Re-run the core cases after every release.

A full example: a restaurant and its booking system

Comparison

Where does it sit between manual testing, a freelancer and the tools?

Each way of working has its place. This compares the approaches, strengths and weaknesses included.

Fanann’s QA engineerTesting by hand yourselfA freelance testerRecord-and-replay tools

How you startDescribe what you want in plain words and review the planOpen the app and try what you rememberBrief them and agree on scope and datesRecord every flow yourself, click by click

Who decides what gets testedIt proposes a plan from your app and you edit itYou, from what comes to mindThe tester, by experience and time availableYou; the tool only replays what you recorded

After every changeCases are saved and re-run in minutesYou redo everything by handA new round each timeReplayed automatically while the recording still works

When the interface changesTries once to adapt the step, otherwise flags the case “needs review”You adapt naturallyThe tester adaptsThe recording breaks and you redo it

What a report looks likeScreenshot, steps, expected versus actualNotes and screenshots you collect yourselfVaries from one tester to anotherPass or fail; the explanation is on you

Confirming a fixA passing retest is required to closeYou remember to try againBy asking for a verification roundBy replaying

Look, feel and ease of useTests what can be checked; taste stays with youAt its bestStrong, especially at exploringNot covered

What it does not coverStore apps on devices, multiple browsers, load, securityWhatever did not occur to youDepends on the agreementEverything you did not record

A general comparison of approaches, not of any particular product. Human judgement remains the best for look, feel and ease of use.

Safety and limits

Add your site’s address and start, within the limits you set

Apps built with Fanann need nothing: they live in your workspace. An external site or API only needs its address, and by adding it you confirm it is yours or that you are allowed to test it. After that you decide: live or staging, whether test data may be created, and what must never be touched.

How to test your existing site

Add the address and start

Nothing to set up on your site and no waiting. By adding the address you confirm it is yours or that you are allowed to test it. Apps built with Fanann need nothing at all.

Read-only by default

Anything that creates or changes data is off until you allow it, and we suggest staging before live.

Your secrets are masked

Test accounts are stored encrypted, and passwords and tokens are masked in screenshots and reports.

View only

You watch the engineer work in a view-only live picture that only members of your workspace can see.

Inside your site only

Requests stay within the address of the site you added, at a gentle pace that does not strain your site. Internal and private addresses are refused.

A limit on every run

Each run has a time and credit limit. When it is reached the engineer stops and tells you what was actually done.

Trust center: security and privacy at Fanann

Paid plans

Part of your paid plan, at a cost you see before a run

The QA engineer is part of Fanann’s paid plans and is not in the free plan. Before each run you see its estimate in credits, and inside the app you see how much of this month’s allowance you have used.

Compare the plans Create a free account

Runs use your credits, with monthly allowances that depend on your plan
Testing external sites and APIs depends on the plan
Scheduled runs, report export and sharing are on higher plans
“Ask Fanann to fix it” is for Fanann apps and is charged like any change you ask the builder for
A clear warning when you are close to your plan’s limit

Plainly: what the QA engineer does not do

The web, not store appsIt tests websites and web apps in a real browser, phone size included. It does not test store-installed mobile apps on real devices.

One browserTests run in one real browser. We do not promise coverage of every browser.

No load, no pen testIt is not a load test for thousands of visitors, and not a security audit or penetration test. Those need specialists.

Never edits your external siteFanann fixes apps built with Fanann. For an external site you get the steps and the diagnosis; the fix is your developer’s.

FAQ

Questions people ask about the QA engineer

What is Fanann’s QA engineer?

An AI QA engineer you assign work to in plain words. It gets to know your app, proposes a test plan you review, runs it in a real browser, writes an evidence-backed bug report for everything it finds, tracks each bug until a retest proves it fixed, and tells you whether the app is ready to launch.

Do I need testing or coding experience?

No. You write what you want tested the way you would explain it to a new team member, and answer simple questions: where is the app, should I test the live site or a staging copy, may I create test data? The test cases themselves are readable steps, not code.

Can it test a website that was not built with Fanann?

Yes. Add your site’s address and start, with nothing to set up on the site itself. By adding it you confirm it is yours or that you are allowed to test it. Then it tests the site’s pages, forms and flows. The difference is that the fix is your developer’s: we hand you the steps and the diagnosis and do not change your site’s code.

Are the tests real?

Yes. Tests are actually executed in a real browser against your app, and every result, number and bug you see in your account comes from a run that happened. The drawings on this page are illustrative examples, and “Rose Café” is an example, not a customer.

Will it change my data or place real orders?

Not without your permission. Tests that create or change data are off by default and are skipped in the run with the reason stated. If you allow them, we recommend a staging copy and test accounts, and you decide what must never be changed.

When does a bug count as fixed?

When the retest passes. Clicking “done” only moves the bug to ready for retest; then the cases linked to it are run again. If they all pass, it becomes “verified fixed”. Workspace admins have a manual override, which requires a written reason and is clearly labelled as a manual override.

Does it test mobile apps?

It tests websites and web apps in a real browser, including at phone screen size. It does not test store-installed apps on real devices, we do not promise coverage of every browser, and it is neither a load test nor a security audit.

Does “ready” mean my app has no bugs?

No. “Ready” means that what was tested passed and that no open bug has the severity that blocks a launch. That is why every report states what was not covered and never claims full coverage.

Which plans include the QA engineer?

The QA engineer is part of Fanann’s paid plans and is not in the free plan. Runs use your credits, with monthly allowances that depend on your plan, and you see the estimate before a run starts. Some features, such as scheduled runs and report export, are on higher plans.

Does it replace a human tester?

It takes over the repetition: re-running the same flows after every change and documenting every bug. What stays with people is judging look and feel, ease of use, and business rules that are written nowhere. Tell it those rules and it will test them.

Go deeper