BitAssure
Sign inGet started

How BitAssure works

You already know how your product is supposed to behave. BitAssure is a way to write that down by doing it once, and then have it checked for you as often as you like.

A phone on a stand in front of a monitor, both showing the same app

The real thing, not a copy of it

Your app is opened on an actual browser and an actual handset, the way a customer would open it. Nothing is simulated, and nothing about your product has to change to be checked.

  • A real browser for your website
  • A real Android or iOS device for your app
  • Your own staging or production address
  1. Link your appa web address or a build
  2. Create a journeya named flow, like signing in
  3. Add checks as you gosay what should be true
  4. Run itwhenever you need to
  5. Read the reportwhat passed, what didn't
The first three steps happen once per journey. After that it is run and read.

Five steps, once

The first three happen once per journey. After that, running it again and reading the result is the whole loop.

  1. 1

    Link your app

    Give BitAssure the address of your website, or upload your app build. It opens the real thing on a real browser or device, not a copy of it.

  2. 2

    Create a journey

    A journey is a named flow you want covered: signing in, checking out, sending money. It holds all the checks that belong to that flow in one place.

  3. 3

    Add checks as you go

    Move through the screens of that flow and say what should be true on each one. "The balance reads P 4,120.00." "The pay button works." Plain sentences, in your own words.

  4. 4

    Run it

    BitAssure repeats the whole journey on demand: before a release, after a deploy, or when a client says something looks wrong.

  5. 5

    Read the report

    Pass or fail, screen by screen, in the words you used. A failure names what broke, what was found instead, and shows you the moment on video.

A journey covers a flow, not a page

Most things that go wrong in software only go wrong partway through something. The basket works but the delivery step silently drops the address. Sign-in works but the account page shows the wrong balance.

So a journey covers the whole flow: you move through it screen by screen, adding your checks as you go, and they all live together under one name you chose.

One journey

  1. Sign in
  2. Basket
  3. Delivery
  4. Payment

What you can check

Deliberately a short list. These are the things that break most often and that anyone can judge without opening a developer tool.

  • Something is there

    A banner, a confirmation message, a delivery date. Anything that should appear on a screen and sometimes silently does not.

  • It says the right thing

    A total, a reference number, a balance. Either exactly what you expect, or containing the part you care about.

  • It actually works

    A button is enabled and can be used, rather than sitting there greyed out because something upstream failed.

Checkout

3 of 4 checks passed

  • Customers can still reach checkout
  • The total adds up correctly
  • The delivery date is shown
  • The promo banner is missingCovered by the basket panel

What comes back

A report, in the words you used, screen by screen. Not a log file, and not a dashboard built for engineers. Something you can forward to a client or drop into a channel without translating it first.

A failure names the check that broke and what was found instead, so the conversation starts at "the promo banner was covered" rather than "something went wrong on checkout".

Three things people ask straight away

  • One failure never hides the rest

    Every check is judged on its own. A broken sign-in button does not stop the run and leave you guessing about everything after it. You still get the full picture.

  • Restyling does not break your checks

    A check holds on to the thing itself, not where it sits on screen. Move it, restyle it, change the layout for mobile: the check still finds it. Remove it, and you hear about it.

  • You can see what happened

    Every run is recorded, and each check is placed in that recording. When something fails you watch the moment rather than trying to reproduce it on your own machine.

Run it as often as it is worth running

There is no per-seat licence and no subscription to idle capacity, so nothing about the pricing discourages you from checking again. You pay for the runs you actually make.

Start runs yourself from the app, or from your own build pipeline using an API key.

Start free See pricing
  • Before a release
  • After a deploy
  • Whenever something looks off