Free test sheet

Before you trust an automation: the 12-check test sheet

Twelve checks to run before an automation touches real records.
Each one says what to do, what a pass looks like and what a failure looks like.

Built with AI assistance. Reviewed by a person, tested by our own test suites.

Download the one-page PDFA4, one page, the same twelve checks.

One-page PDF

Empty input

What to do
Feed it an empty file, a blank row in the middle and a record with a required field left blank.

Pass looks like
Blank rows are skipped. A blank required field is listed with a reason. Nothing is filled in by guess.

Failure looks like
The run crashes, writes a zero where a value was missing, or stops without saying why.

We saw this in our own test
Our spreadsheet sales tracker skips blank rows in the middle and does not count them as errors. Our store product file checker never turns a blank inventory number into zero; the row goes on a list for a person.
Messy input

What to do
Mix date formats (10/04/2025 next to 02 Oct 2025), add stray spaces, capital letters and a currency sign in a number column.

Pass looks like
Each value is read the same way every time, or the row is set aside with its reason.

Failure looks like
Rows disappear without a trace, or a date is read with day and month swapped.

We saw this in our own test
In a deliberately flawed demo script we repaired, 2 rows were lost with no trace before the fix: a US-format date and a bad date. After the fix, 0 were lost, and the bad one is listed in a rejects file with its reason.
Duplicate input

What to do
Enter the same record twice: once as typed, once with different capital letters and a trailing space.

Pass looks like
The first copy counts. Later copies are flagged and left out of the totals.

Failure looks like
Totals double, or the other app gets two records for one.

We saw this in our own test
Our spreadsheet sales tracker flags later copies of an order and leaves them out of the totals; matching ignores capital letters and stray spaces. Our orders-to-CRM sync ended its first run with 0 duplicate deals and 0 duplicate contacts.
Run it twice

What to do
Run the same job again straight away, with no new data.

Pass looks like
The second run creates nothing and changes nothing.

Failure looks like
New copies appear, dates change, or the same customer gets a second message.

We saw this in our own test
We re-ran our orders-to-CRM sync with nothing new to send: 0 created, 0 updated.
Break the connection halfway

What to do
Stop the run in the middle (cut the network or end the process), then start it again.

Pass looks like
After the restart, the end result equals one clean run.

Failure looks like
Half-written records, gaps, or doubles after the restart.

We saw this in our own test
We crashed our orders-to-CRM sync on purpose after 25 writes. After the rerun, the CRM state equals one clean run. Our two-store inventory sync passed the same test after a crash 3 orders in.
Hit a limit

What to do
Push past a rate limit, a size limit or a time limit: a 'too many requests' answer, a very large file, a very long run.

Pass looks like
It waits and retries, or pauses and resumes from a saved point, and it says so.

Failure looks like
It stops halfway with no note, or keeps hammering the service.

We saw this in our own test
Our spreadsheet sales tracker paused before row 32 of 62 to stay under the time limit and scheduled a continuation. It also held back its email digest when the mail quota was near zero (3 left, reserve 5).
Count the cost of a retry

What to do
Make one service fail twice before it answers, then count the calls and the time.

Pass looks like
You know how many extra calls a retry costs and where the retries stop.

Failure looks like
Retries with no limit, or extra calls you only notice on the bill.

We saw this in our own test
In the repaired demo script, the fixed version made 13 calls where the flawed one made 9, and the run took 1.26 s instead of 1.03 s. The 4 extra calls were retries for a flaky customer and a slow one, and the slow one is given up after 3 attempts.
Check who sees the data

What to do
Start with test data. Read the logs and outputs for keys, passwords and personal details before real data goes in.

Pass looks like
No keys or personal details in logs or outputs. Real data goes in last.

Failure looks like
An access key or a customer email address printed in a log file.

We saw this in our own test
The flawed demo script wrote its API key into 9 log lines. After the fix: 0. Our PDF statement and invoice reader runs its tests with the network blocked: 0 connect attempts.
Find the reviewer and the stop button

What to do
Find where a person looks before anything hard to reverse happens, and how to pause the job.

Pass looks like
Doubtful records go to a review list. The job can be paused without leaving half a result.

Failure looks like
Everything is written straight through, and nobody knows how to stop it.

We saw this in our own test
Our store product file checker left 19 review items for a person instead of guessing. Our PDF reader sorted 37 files into 28 ok, 6 to check and 3 rejected. Our two-store inventory sync lists an oversold order to cancel or back-order; it does not cancel orders itself.
Plan the undo

What to do
Before the first real run, write down how you would undo it: a copy of the file, a backup, or a list of every record the run wrote.

Pass looks like
You can put things back as they were, from a list of what changed.

Failure looks like
The only record of what changed is the changed data itself.

We have not tested undo in our own kits yet, so there is no note from our runs here.
Read tomorrow what happened today

What to do
After a run, open its log or report. Count records in, records out and records set aside.

Pass looks like
The counts add up, and every record set aside has a reason.

Failure looks like
No log, or counts that do not add up.

We saw this in our own test
Our orders-to-CRM sync ends each run with a check that must add up: shop orders 30 = CRM deals 26 + open rejects 4 -> OK. Our spreadsheet sales tracker writes plain-words entries to an error log when it skips or stops something.
Change the format on purpose

What to do
Rename a column, reorder the columns, or feed it a layout it has not seen before.

Pass looks like
It stops writing and names what changed.

Failure looks like
Values land in the wrong fields and the run still reports success.

We saw this in our own test
When someone renames a column, our spreadsheet sales tracker writes nothing and its error log names the column. Our PDF reader rejects a layout it does not recognise. A hand-renamed product file showed 49 errors in our store product file checker; the converted file showed 0.

Have an automation you do not trust yet?

Want one of these checks run on your own automation, or a tested kit for your shop? Email [email protected] or send a DM to @breakitfirstlab on X.

Ask about a kit Email us DM us on X

Download the one-page PDF

Empty input

Messy input

Duplicate input

Run it twice

Break the connection halfway

Hit a limit

Count the cost of a retry

Check who sees the data

Find the reviewer and the stop button

Plan the undo

Read tomorrow what happened today

Change the format on purpose

Have an automation you do not trust yet?