How to test an AI-built app

🧪 Testing means proving a result, not clicking around

Start with one sentence: ‘A new customer can choose a service, submit valid details and see the same booking after a reload.’ That sentence is the contract. Every test changes one condition and checks whether the result still makes sense.

An AI-built app can look unusually finished before its awkward paths have been exercised. Treat the polished preview as the beginning of testing, not evidence that testing is over. The goal is not to find every theoretical bug; it is to protect the jobs and information people will rely on first.

Prepare a safe test kit

Test version

Write down the exact project version or revision before you begin.

Fictional data

Use names, messages, files and addresses that belong to nobody real.

Two roles

Have separate safe accounts when permissions or private records matter.

Device widths

375px phone, 768px tablet and a wide desktop are a useful minimum.

Expected result

Write what should happen before each test, not after seeing what happened.

1. Turn the central journey into a test map

List the app's states in order: empty, partly filled, valid, submitted and confirmed. Then add the meaningful detours—invalid input, no results, cancelled payment, expired session or a second press. You now have a small map instead of a pile of buttons to poke.

Keep each row concrete. ‘Test bookings’ is not a test. ‘Choose Group walk, leave Mobile number empty, press Confirm and remain on the form with the Mobile number error in view’ is repeatable and has one expected result.

2. Run the happy path from a clean start

Open Preview as though you have never seen the app. Start at its real entry screen, follow the obvious action and complete the central journey with valid fictional details. Do not use hidden developer shortcuts or a state that was left open from yesterday.

At the finish, look for an observable result: a confirmation reference, a new row, a changed status or a provider record. A green tick alone proves only that somebody drew a green tick. Navigate away and return where appropriate; a finished action should still be true when the celebratory screen is gone.

1. Reload the preview and begin from its intended first screen.
2. Use valid but deliberately long fictional names and labels.
3. Complete every required action without skipping ahead.
4. Record the final screen, route and saved result.
5. Navigate away, return and confirm the result still exists where promised.

3. Test the phone with the longest real content 📱

Switch Preview to the phone frame and start again. A responsive app is not a desktop app squeezed narrower; priorities change. The main action must remain reachable, the keyboard must not cover the field or final button, and fixed navigation must not sit on top of the content.

Use the longest believable service title, customer name, price and error message. Short seed data hides the exact wrapping and overflow problems that real content creates. Rotate or widen to tablet where the layout changes, then check desktop rather than assuming the same rules simply stretch.

• No horizontal page scroll at 375px.
• Headings wrap without covering controls or leaving one orphan word.
• Buttons and icon controls have comfortable tap areas and visible labels.
• Menus, dialogs and bottom sheets fit inside the visible screen and can close.
• The final action remains reachable when content grows or the keyboard would be open.
• Focus is clearly visible for somebody using a keyboard on tablet or desktop.

Tip. Do not test mobile by making the desktop window vaguely narrow. Use the named phone frame or an exact 375px viewport so the failure can be reproduced.

4. Make the input wrong on purpose

A useful error appears beside the thing that needs attention, preserves good work and explains how to continue. Trigger each required-field error, a wrong format and the longest allowed input. Then try something just beyond the limit so you know the boundary is enforced rather than merely written in help text.

Repeat the final action quickly. A booking, payment or upload should not quietly happen twice because a person double-clicked, went back or lost patience on a slow connection. If the app is still working, show a busy state that does not erase the person's context.

5. Reload midway and repeat the action

Reload once with a half-completed task and once after a completed task. Decide which information should survive. A public calculator may correctly start over; a saved job edit should not disappear after claiming it was saved. The important thing is that the behaviour matches the promise on screen.

Open a second tab where concurrent use matters. Change the same item in both tabs and observe which version wins. The app should not silently overwrite a newer edit with an older one. A clear conflict or refresh request is better than a neat screen carrying lost work.

Note. Preview environments may deliberately restrict storage or external requests. Record that as unavailable and repeat the required check on the deployment-equivalent version; never relabel an unavailable test as passed.

6. Prove private data with two people, not one

Sign in as two fictional roles when the app has accounts, staff views or private records. Create one record as Person A, copy its address and try to open it as Person B. Hiding the link in the interface is not permission; the server or data rules must refuse the wrong person even when they know the address.

Test the boring boundaries too: signed out, expired session, disabled account and a role missing the permission. Do not use a real customer's account to prove any of this. A safe test account should be disposable and contain nothing that matters outside the test.

1. Create one fictional record as the ordinary role.
2. Open it successfully as its owner.
3. Try the same direct address as a different ordinary account.
4. Try it signed out and with the least-privileged role.
5. Confirm the refusal reveals no private title, count or content in the response or screen.

7. Test every connected service on both sides

For payments, email, uploads, maps or other services, check the app and the provider record. A redirect back to ‘Success’ is not enough. The provider should show the matching test event, and the app should grant only the thing that event actually completed.

Exercise success, cancellation and failure separately. Keep provider test mode on until the result and recovery wording are correct. If a service is not connected in the test environment, mark the check unavailable, state what remains to be proved and block any claim that depends on it.

• The request leaves the app with the expected test identifier.
• The provider records the matching event or gives a specific refusal.
• Returning to the app does not create success on its own.
• A retry does not duplicate the bought item, message or upload.
• A failure tells the person whether to retry, change input or contact somebody.

8. Finish with a tiny release receipt ✅

Write down the exact revision, viewports, journeys, roles and connections tested. Use four honest outcomes: passed, failed, unavailable and skipped. A timeout is unavailable. A test you forgot is skipped. Neither becomes clean because no red message appeared.

Fix hard failures, rerun the affected journey and check that a previously working path did not regress. Keep the receipt beside the release. It is short enough to maintain and specific enough to stop a team arguing from memory.

Common questions

What is the first thing to test in an AI-built app?

The central journey from a clean start. Complete it with valid fictional data and confirm the promised result still exists after navigating away or reloading where persistence is expected.

How do I test an app on mobile?

Use an exact phone viewport such as 375px, the longest believable content and the complete journey. Check horizontal overflow, menus, fixed controls, keyboard space, tap targets and the final action—not only the first screen.

Do I need automated tests?

Automation is valuable for repeatable business rules and regression checks, but it does not replace using the rendered app. Begin with explicit manual journeys, then automate the stable high-risk paths that need to run after every change.

Can I test payments with a real card?

Use the payment provider's test mode and documented test details first. Prove success, cancellation and failure without moving real money, then perform only the smallest authorised live verification required for launch.