Skip to content

Test an app you built with AI

Step 6 of 10 in the builder spine.

Write down 10 to 20 real examples, each with the answer you expect, including awkward ones: empty, duplicate, wrong format, very large, and someone without access. Run them before every release. Add a check that a person without access can't see the data, and reconcile totals against the source system. From Team up, these test cases must pass before every release (gate matrix).

Who this is for

Builders who aren't developers, and anyone checking their work. You need a spreadsheet and a colleague's time, not code. About 10 minutes to read, and an hour to write your first set.

An AI tool will tell you the app works, but its say-so is not a test. Writing the expected answer before you run the example is what makes it one.

How do I write test cases?

Start from the spec you wrote (write a build spec): each rule in it becomes at least one case. Use real examples from the work, with personal data removed or made up. Keep them in a table next to the app record, or start from the test case tracker (CSV). Prompt to Prototype, Test an app you built with AI, https://prompt-to-prototype.com/build/test-your-app/, as of 2026-10-22. Licensed CC BY-SA 4.0. Using or adapting it inside your business isn't distribution under the licence. Example:

ID What I do Expected result Result and date Notes
T-01 Enter an invoice with a PO number that matches Status shows Matched Pass, 2026-10-12
T-07 Upload a file with a blank amount A clear error; nothing saved Fail, 2026-10-12 Saved a zero. Fixed in v3
T-12 Sign in as a user outside Finance; open the invoice list No invoices, or "no access" Pass, 2026-10-12

Illustrative composite

Three rows from an invoice-matching tracker (invented). Your set should hold 10 to 20 rows to start. Add a row each time the app fails in use.

Write the expected result in words a colleague could check, such as "Status shows Matched".

Which awkward cases should I try?

Try each of these on every screen or step that takes input:

  • Empty. No value, a blank file, no rows.
  • Duplicate. The same record twice; the same file uploaded twice.
  • Wrong format. Text where a number belongs, a date in another format, a name with an accent or an apostrophe.
  • Very large. More rows than usual, a long text, a big file.
  • Very small or odd. Zero, negative numbers, a single row.
  • Two at once. Two people editing the same record.
  • Someone without access. See the next section.
  • A dependency is down. The connected system is slow or unreachable; the app should say so, not show stale numbers as current.

Test the unhappy paths first. In practice, apps built by AI often get the typical case right and fail quietly on the rest (practitioner experience, not a measured result).

Don't: test only the happy path

A test set made only of normal inputs tells you the demo works. Several documented failures came from oversized or oddly formatted inputs (AP18; failure patterns).

How do I test who can see what?

Run the access tests before you share the app, and after every change to sharing, data or sign-in. They are the same tests the security pages describe, so this page doesn't repeat them: follow how to test your app without a developer. In short, there are six checks: signed out, second account, share settings, key search, a direct database query with the public key, and the platform's own checker. The direct query is the one that catches missing data rules. The security checklist covers the rest, and the pre-release check says how deep to go for your tier.

Add one case per role to your table: "Sign in as ; try to open ; expected: ". From Important, negative access tests (a person without access is refused) are a gate, and the technical reviewer repeats them.

How do I reconcile totals?

If your app loads, transforms or totals data, check that nothing was lost or changed on the way. This is the fact-check step of the verify self-check.

  1. Count rows. Rows in the source, rows loaded, rows rejected. Source must equal loaded plus rejected, and every rejection needs a visible reason. Examples of how: the source system's own report or export row count, and a spreadsheet's COUNTA or status-bar count (Excel, Google Sheets, LibreOffice Calc). A spreadsheet can itself truncate a large file (current Excel stops at 1,048,576 rows), so for big CSV files count lines instead, with PowerShell's (Get-Content file.csv).Count or the line number at the end of a text editor.
  2. Total a number. Sum an amount, a quantity or a headcount in the source system and in the app. They should match to the cent, or you should be able to explain the difference. Examples of how: SUM or a pivot table in a spreadsheet, and the source system's own summary report.
  3. Spot-check ten records end to end, from the source value to what the app shows.
  4. Look for silent changes. Long numbers shortened, leading zeros dropped, names or codes turned into dates, text cut off at a length limit. When you import a CSV, set the column type to Text: in Excel use Data > From Text/CSV, and in Google Sheets turn off "Convert text to numbers, dates and formulas" in the import box.
  5. Check what the AI says it did. Compare its summary of what it built or changed against the version history or change log, and check any figure or source it quotes against the data.
  6. Repeat after every change to the data source, the import or the formulas.

The tools above are examples, not endorsements.

These checks catch silent failures, which are the dangerous kind because nobody sees an error. England's public health agency left 15,841 positive COVID-19 cases out of its reports for a week in 2020 because of a row limit in an old spreadsheet file format used in a data load.1 A 2016 study found that 704 of 3,597 genomics papers with gene lists in Excel had names auto-converted to dates or numbers.2 A row count would have caught the first, and a spot-check the second.

Don't: let an import truncate or convert silently (AP18)

If the source has 10,000 rows and the app shows 9,990, find the ten before you trust either number. Make the app report how many rows it read.

What accessibility checks apply to an internal app?

An internal app isn't exempt from accessibility. Staff who use a screen reader, a keyboard only or a zoomed screen need to do their job in it, and employers can have duties to accommodate them. The technical target is WCAG 2.2 level AA. What the law requires in your situation is covered on production ready: accessibility, with the gates by tier. Not legal advice; as of October 2026, ask your counsel what applies to you.

For the one to three core tasks the app exists for, check these yourself (about 20 minutes). Run an automated scan first: examples are the axe browser extension, WAVE, Accessibility Insights and Lighthouse. A scan finds only some problems, so also try the main task with a screen reader (examples: NVDA, VoiceOver, Narrator). Tools here are examples, not endorsements. The full list, including the screen-reader task and the WCAG 2.2 additions (focus not obscured, 24 px targets, accessible authentication), is the ten accessibility checks (CSV).

  • Keyboard only. Put the mouse aside. Press Tab: you can reach every button and field, the order makes sense, and you can always see where you are.
  • Labels. Every field has a visible label that stays on screen while you type, and buttons and links say what they do ("Save invoice", not "Click here").
  • Contrast. Text is clearly readable against its background. Text needs a contrast ratio of at least 4.5:1 (3:1 for large text and controls). Examples of checkers: the WebAIM contrast checker and the Colour Contrast Analyser.
  • Zoom. Zoom the browser to 200%, then 400%. Nothing disappears or overlaps.
  • Errors. When something's wrong, the message says what and where, in words, not by color alone (WCAG 3.3.1).

At Team these are good practice. At Important and above, the check is a gate if people outside the business use the app or receive messages it sends; otherwise it is good practice on the core tasks. Record what you tested, when, and who did it. Never write that the app "is accessible" unless a person tested it.

Can I ask the AI to write the tests?

Yes, with a check. AI is good at suggesting cases you didn't think of. But a test the AI wrote from its own code often just asserts that the code does what it does. Ask it to write tests from your spec before it sees the code, read each one, and make sure at least one fails when you deliberately break a rule.

Don't: trust AI-written tests you haven't read

A suite that passes proves little if the tests copy the code's behavior. Builders ship AI output unreviewed unless the process makes review visible (A-021). Your table of expected results, written first, is the visible review.

How do I keep the tests for later changes?

Store the table with the app record (document your app), not in your own drive. Every change, including a changed prompt or an updated tool, re-runs the whole table before release (change a worker-built app safely). Note the last passing date in the record.

If the app contains an AI feature, ordinary test cases aren't enough, because the same input can give different answers: use evals as well.

When should I ask a developer for help?

Ask when you can't state the expected result, when the app changes data in other systems, or when a test fails and you can't tell why. Your champion or IT's intake route can connect you (enablement and training).

Assumptions and evidence

  • A-021 (Low for non-developers): Hypothesis. We expect builders to run tests only when running them is visible and expected; test this by checking, in your pilot, whether the app record shows a passing date for each release.
  • Evidence: public incident reports and a research paper on silent data changes. No study of testing by non-developer builders exists.
  • Facts on this page are as of October 2026.

  1. The Register, Excel spreadsheet error in England's COVID-19 contact tracing, 5 Oct 2020, https://www.theregister.com/2020/10/05/excel_england_coronavirus_contact_error/ [news], accessed 2026-10-22. ↩

  2. Ziemann, Eren and El-Osta, Gene name errors are widespread in the scientific literature, Genome Biology 17:177, 2016, https://doi.org/10.1186/s13059-016-1044-7 [research], accessed 2026-10-22. ↩