Does your app still finish the job after a change?
Test one task a customer depends on. A booking should appear after you reopen the app. An unavailable time should offer another choice and leave no extra appointment.
Which task should you check first?
Start with the one result a customer came for. A booking app must save a slot the customer can find later. A contact form must send the message somewhere you can receive it.
A page can look finished and still lose the result. Before you write a test, describe what the customer should see and what the app should remember. Decide what the customer should be able to do if the task fails.
| Question | Check to try | Evidence to keep |
|---|---|---|
| Does the job still work after a change? | Repeat one saved booking and one unavailable slot. | The confirmation, the reopened appointment and the expected failure message. |
| Can someone finish on their phone? | Use the form with the on-screen keyboard open on a phone and check that the next action remains reachable. | The device, browser and step where the customer got stuck. |
| Did a visual change break a layout? | Compare a known-good image and the current screen with the same fake data and screen size. | The part of the page that changed and whether the change was intended. |
On a small screen, scroll the table sideways to read every column.
How do you test one booking without touching customer data?
Run the same small journey by hand first. Use a test copy so you can safely make it succeed and fail.
- Confirm the test connectionsUse an isolated app, a separate test database and sign-in settings, and disposable accounts. Turn payments off and disable reminders or send them only to a test inbox you control. Stop before saving anything if you cannot confirm the destination.
- Book a time and reopen itUse one test account to reserve a fake slot. Sign in as the same account in a fresh browser session and look for exactly one booking at that time. Reloading in the first browser alone can still show information saved only on that browser. For a private booking, use a second test account to check that it cannot see the first account’s record.
- Check an unavailable timeGive the test app a slot that is already taken. Try it and confirm the app gives another choice without saving an extra booking. When you automate this, record the expected result as well as the clicks.
- Make sure your check can failOn the disposable copy, simulate a confirmation without saving. The check for the reopened appointment should fail. Restore the normal save and confirm it passes again. Keep the reason for the failure with the result.
Compare tools
Scroll the table sideways to read every column.
| Tool | What you verifyWhich part of the customer’s task the tool helps you check. | Where the test runsThe machine, browser or device that actually does the work. | What you see when it failsWhat you can inspect to find the first step that went wrong. | What test data reaches itWhere accounts, logs and recordings can go. | What you pay for and keepThe main cost unit and what stays with your project. |
|---|---|---|---|---|---|
| Playwright | Write or record a browser test, then add checks for what the customer sees and what is still saved after reload. | Run on your computer or an automated runner. Covers Chromium, Firefox and WebKit. A phone profile can simulate screen and touch settings. | Review the failed check and a trace of what the browser did when configured to collect one. | Use separate browser sessions and a test database. Keep saved sign-in state and test artifacts private. | The open-source runner has no subscription fee. Keep the test files and pay separately for any hosted runner or artifact storage you use. |
| Cypress | Record the first flow interactively in Studio and add checks for the result. Keep and edit the generated test in your project. | Run the Cypress App on your computer or an automatic runner. It supports Chrome-family browsers and Firefox, plus experimental WebKit. | Inspect the interactive command log or run screenshots. Optional Cloud Test Replay is available for supported Chromium runs. | Use independent test accounts. Cloud recording can send test content and artifacts. Optional Studio AI can send page information even during the trial without an account. | The Cypress App has no subscription fee. Optional Cloud plans count individual recorded results and have separate retention limits. |
| BrowserStack | Open your app on a particular remote phone or browser and perform the same task yourself. Automate can also run scripts you already own. | Live uses remote browsers and physical devices on supported plans. For scripted runs, check the exact tool, browser and device combination. | Keep the browser and device details with what you observed. Check your plan for session recordings, logs and retention. | A remote browser needs the test URL and test account. Use an approved private test connection if the site is not public. | Live plans vary by people, device coverage and time allowance. Automate plans count how many tests can run at once. Keep essential notes and artifacts separately. |
When do you need a real phone?
Use a real phone when the task depends on behavior an emulated screen may not reproduce, such as a keyboard covering a button or scrolling a form on mobile Safari.
A narrow browser window checks the layout at that width. A device profile can also mimic touch and other settings. A real phone runs the browser and operating system the customer actually uses.
Repeat the same test on a device and browser you expect customers to use. Write down the device, browser and step if you find a difference. Check the path with a keyboard too, including whether you can see where focus is and reach the confirmation.
What should a failed test tell you?
A useful failure tells you which expected result was missing. Keep enough evidence to tell whether the app saved the booking, the browser lost the response or the test started with the wrong data.
If the same check passes on a rerun, you still need to know what changed. Look at the starting slot, the saved result and the first point where the test disagreed with the app. Make each run start with its own predictable records.
For a visual comparison, review the changed area before accepting a new reference image. Keep the browser, screen size and fake records consistent so the comparison can show the change you meant to check.
Which parts need their own checks before launch?
Use a separate check for each service or promise the customer depends on. Saving an appointment does not prove the payment, email or account access works.
| If the app needs this | What to verify |
|---|---|
| Sign-in and private bookings | Use separate test accounts and check that each sees its own saved records. Check sign-in and sign-out separately. |
| Payments | Use a test payment environment with its own settings and fake payment details. Check what the app saves on success and decline. |
| Confirmation email | Send to an inbox you control. Verify the message arrives once, goes to the intended test recipient and points to the test app. |
| An automatic release check | Use the same isolated setup when the tests run after a code change. Decide which failures stop the release and where you can inspect them. |