Skip to contentTalk to us
العربيةLog inStart free
Bug tracking

Every bug gets a card. It closes only on proof

No spreadsheets to get lost in and no “try it now” messages. Every bug the QA engineer finds becomes a clear card: what it means for your business, how to make it happen again, what should have happened, what actually did, and the screenshot. The card stays open until the retest passes.

Start freeHow it works
Evidence with every bugA fix is proven by a retestPart of the paid plans
Why it matters

A bug nobody follows comes back

1

“It works for me”

The customer says the order did not go through and the developer cannot make it happen again. Without clear steps and a screenshot, the time goes on back-and-forth.

2

“Done” with no proof

Someone clicks “done” and the matter is closed, then your customer discovers the bug is still there. The word “done” is not evidence.

3

An old bug shows up again

A small change in one place breaks something that was fixed a month ago, and nobody notices because nobody tested it again.

1The bug lifecycle

“Fixed” is written only after a passing test

Every bug follows a clear path: new, confirmed, in progress, ready for retest, then “verified fixed”. Clicking “done” only moves it to ready for retest. The QA engineer then re-runs the test cases linked to it, and if they all pass the bug is stamped verified. Admins have a manual override when it is needed; it requires a written reason and is visibly labelled as a manual override.

  • A retest in one tap from the card
  • A bug that returns is marked “regressed”, history kept
  • Manual override with a written, visible reason
2The bug card

Impact first, then the detail for whoever fixes it

The card opens with what matters to you: what your business loses if the bug stays. Then a short title, steps that reproduce it, expected beside actual, the screenshot from that very run, and the linked test cases and runs. Severity is one thing, priority another and confidence a third, and each is shown on its own. A likely cause appears only when the evidence supports it, and it is labelled likely, not proven.

  • Severity: critical, high, medium, low
  • First seen, last seen and how many times
  • Assignee, comments and activity history
3The whole picture

A clean list: no duplicates, no noise

When the same defect fails several test cases, it is grouped into one bug instead of flooding the list. If a report turns out not to be a real bug, you mark it a false positive and it stays on record. With every run you see what is new, what was fixed and what regressed, so you know whether your app is getting better.

  • Duplicates grouped into one bug
  • False positives can be marked
  • New, fixed and regressed in every run
Examples

From a sentence you say to a documented bug

You write what worries you in your own words; the QA engineer tests and documents.

The discount code applies twice

A high-severity card appears: the steps that repeated the discount, the expected total against the actual one, and a screenshot of the cart page.

Try the discount code in the cart and make sure it cannot be counted more than once.

The pay button is hidden on phones

The bug is filed with a phone-size screenshot showing the button off screen, and linked to a test case that is re-run after the fix.

Open the checkout at phone size and see whether everything is visible and tappable.

The developer says it is fixed

The QA engineer re-runs the cases linked to the bug. If they pass it is stamped “verified fixed”; if they fail the bug goes back to open with the new evidence.

Retest the sign-in bug and confirm for me that it is really gone.
The steps

From found to “verified fixed” in five steps

The same path for every bug, in an app built with Fanann or on your external site.

  1. 1

    Run a test round

    Tell the QA engineer what you want tested in your own words. It proposes a plan you review, then runs it in a real browser.

  2. 2

    Review the bugs that turned up

    Every case that failed because of the app becomes a bug card with impact, steps, expected vs actual and a screenshot. Duplicates are grouped into one card.

  3. 3

    Confirm and set priorities

    Confirm the real bugs, mark the false positives, assign an owner and decide what gets fixed first by severity and business impact.

  4. 4

    Fix

    In an app built with Fanann you ask Fanann to fix it from the card. On an external site your developer takes the steps and the evidence and fixes it.

  5. 5

    Retest

    The QA engineer re-runs the cases linked to the bug. All passed? It is stamped “verified fixed”. Failed? It goes back to open with the new evidence.

Plainly: what you should know

External sitesFanann does not change the code of a site it did not build. You get the steps, the evidence and a likely cause; the fix is your developer’s.
Likely causeA diagnosis is given only when the evidence supports it and is labelled likely. It is not a final ruling on the code.
Coverage limitsThe list holds what the tests that ran found. An empty list does not mean an app with no bugs.
Depends on planThe QA engineer is part of the paid plans, and report exports, share links and scheduled runs depend on your plan.
FAQ

Questions people ask

What is a bug tracking system?
One place where the bugs of your app or website are recorded and followed from discovery to fix. In Fanann the QA engineer fills it from real test runs, so every bug arrives with its steps and evidence and you do not write the reports by hand.
When does a bug count as fixed?
When a retest passes. Clicking “done” only moves the bug to ready for retest; then the test cases linked to it are re-run. If they all pass it becomes “verified fixed”, shown together with the run that proved it.
What is the difference between bug severity and priority?
Severity describes how much damage the bug does: critical, high, medium or low. Priority is your decision: what gets fixed first. A medium bug on checkout may come before a high one on a rarely visited page. That is why Fanann shows them separately, along with the confidence in the report.
What does a bug report in Fanann contain?
A short title, the impact on your business, severity, steps to reproduce, expected vs actual, screenshots from the run, linked test cases and runs, first seen, last seen and how many times, the assignee, comments and an activity history.
What if a bug comes back after it was fixed?
If a test linked to a verified bug fails again, the bug is marked “regressed” and reopened. Its whole history is kept: when it appeared, when it was fixed and when it returned.
Does Fanann fix the bugs itself?
For apps built with Fanann: yes, you ask Fanann to fix the bug from its card, then the test cases are re-run. For external sites and systems: no, Fanann does not change their code; it gives your developer the steps, the evidence and a likely cause.
Is bug tracking in Fanann free?
Signing up to Fanann is free. The QA engineer, bug tracking included, is part of the paid plans. Report exports and share links 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

Website testing

Is your site built outside Fanann? Add its address and have the QA engineer test its pages, forms and flows in a real browser.

See the details

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

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
Guide: how to write a bug reportRegression testingTest your Fanann app before launchPlans 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 your app’s bugs before your customers do.

Run a test round, get bugs documented with evidence and follow each one until its fix is proven. The QA engineer is part of the paid plans, and signing up is free.