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

You fixed one thing. Did you break another?

Every change to your app, however small, can break something that worked yesterday. The QA engineer saves each test case as readable steps and re-runs them all after any change, so within minutes you know what is still sound, what broke and when it broke.

Start freeHow it works
Cases saved and re-runCompared with the last runPart of the paid plans
Why now

It is the small change that catches you out

1

What is tested once gets forgotten

Before launch you tried everything with care. Twenty changes later nobody tries the sign-up page any more, until a customer tells you it does not work.

2

Old bugs come back

The bug was fixed and closed, then another change brought it back a month later. Without regular retesting you only find out by chance.

3

Tests written as code need someone to maintain them

Many teams start with automated tests and then abandon them, because every change to a page breaks the test itself and nobody has time to repair it.

1The comparison

What is new, what was fixed, what came back

A run’s result is not read on its own but against the one before. You see the bugs that appeared for the first time, the ones fixed since the last run, and the ones that came back after being fixed. The pass rate across runs shows you where the app is heading: getting better with each release, or slipping.

  • New, fixed, regressed at a glance
  • Pass-rate history across runs
  • You know which run something broke in
2Proven fixes

A bug is not closed by the word “done”

When the developer says the bug is fixed, the card moves to “ready for retest”, not to “fixed”. The cases linked to it are re-run, and if they pass it is stamped “verified fixed” along with the run that proved it. If the same test fails again later, the bug is reopened as “regressed”, with its whole history kept.

  • “Fixed” means the retest passed
  • A returning bug reopens automatically
  • History and evidence are kept
3Without the upkeep

Tests that adapt, and do not blame your app unfairly

A button’s label or position changed and the step can no longer find it? The QA engineer tries once to adapt the step to the new page. If that works a new version of the case is saved; if not, the case is flagged “needs review” and no bug is filed against your app. A result that passes one time and fails the next is labelled “flaky”, not hidden.

  • One attempt to adapt the step
  • “Needs review” instead of a false bug
  • Flaky results labelled, not hidden
Examples

When do you re-run the tests?

Whenever something changes. Here are three common moments.

After changing the checkout page

You added a new payment method. All the purchase cases are re-run to make sure the older methods, the cart and the discounts still work as before.

We added a new payment method. Re-run all the purchase tests and tell me whether anything was affected.

Every morning before work starts

On higher plans you schedule a run that goes on its own at a time you choose, so you start the day knowing that booking, sign-up and payment are sound.

Run the booking and payment tests every morning and alert me if anything fails.

After a bug fix

The case that exposed the bug is re-run, along with the cases around it, to make sure the fix worked and did not break something close by.

The developer says the double booking is fixed. Retest it and make sure the rest of booking is still fine.
The steps

How to set up your recurring tests in five steps

Build them once, then re-run them whenever something changes.

  1. 1

    Start with what must not break

    Tell the QA engineer which flows your business rests on: sign-up, booking, payment. It proposes test cases for them and you review them.

  2. 2

    Run the first round and save the cases

    After the first run the cases are saved with their readable steps, in suites. They are your reference for everything that follows.

  3. 3

    Re-run after every change

    One press re-runs the whole suite. A re-run carries out the saved steps as they are, so the result is fast and consistent.

  4. 4

    Read the difference, not the list

    Look at what changed since the previous run: new bugs, fixed bugs and bugs that came back. Go through the cases flagged “needs review”.

  5. 5

    Schedule runs if your plan includes it

    On higher plans set a fixed time for the run, daily or weekly, so it happens without you having to remember.

Plainly: what you should know

Covers what you savedA passing run means the saved cases passed, not that the app is bug-free. Add a case for every new feature.
Some cases need youWhen a page changes a lot, a case may be flagged “needs review”. Updating it takes minutes, but the call is yours, not the machine’s.
Scheduling by planScheduled runs are available on higher plans. On the others you re-run the round yourself with one press whenever you like.
Web and API onlyIt re-tests websites and web apps in a real browser, and re-runs API checks. Mobile apps installed on devices are out of scope.
FAQ

Questions people ask

What is regression testing?
It is re-running the same tests after every change to make sure what worked still works. The name comes from the app “regressing”, slipping back from a sound state it used to be in. The point is that you find what a change broke before your customers do.
When do I need regression testing?
After any change that reaches your customers: a new feature, a bug fix, a design update or a new integration. The more your business depends on the app, the wiser it is to re-test regularly even when nothing obvious has changed.
Do I need to write code for regression tests?
No. Test cases in Fanann are saved as readable steps: open the page, press the button, check the text. You read and edit them in a simple form, or describe the change to the QA engineer in your own words.
What happens to the tests when a page’s design changes?
If a step can no longer find its element, the QA engineer tries once to adapt it to the new page. If that works, a new version of the case is saved. If not, the case is flagged “needs review”, and that is not filed as a bug against your app.
What does a “flaky” result mean?
A case that failed and then passed on a retry within the same run. It is neither counted as a clean pass nor hidden: it is labelled for you to look into, since it may point to intermittent slowness or unstable behaviour in the app.
Can I schedule the tests to run automatically?
Yes, on higher plans. You set a time for the run and it goes on its own, with the result waiting for you. On other plans you start the run yourself with one press.
Is regression testing in Fanann free?
Signing up to Fanann is free, and the QA engineer is part of the paid plans. The number of cases and runs, and scheduled runs, 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

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
Bug tracking to verified fixTest your Fanann app before launchWhat is software testing?Plans 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

Change your app without holding your breath.

Save your tests once, re-run them after every change and know within minutes what still works. The QA engineer is part of the paid plans, and signing up is free.