Your machine caught its first bug yesterday, which makes today’s question urgent: what else deserves a place in the suite, and what does not. Not every test deserves to be automated, and most suites ignore that until it is too late.
The Monday morning question
For every test you consider automating, ask: if this failed on Monday morning, would the team drop everything to look? If yes, automate it. If no, do not. Then the follow-up: what does this test prove. If you cannot answer in one sentence, the test is not scoped yet.
What passes the question, on almost any product:
- The money paths. Sign in, search, cart, checkout, payment. On Tumble Kitchen: search finds dishes, the cart totals correctly, the discount applies when promised.
- Data integrity. The price on the card matches the price in the feed. The total matches the items. On a real retail platform I tested, the promotion tests that mattered sat at the tier boundaries, just below, exactly at, and just above each threshold, because that is where the money bugs live. Remember that; it becomes very real on Day 16.
- Regressions. Any bug that got fixed gets a test that fails if it returns. Bugs return. Your quarantined cart test from yesterday is already this, waiting.
What fails the question:
- Every field on every form. Cheaper to check by hand and in unit tests.
- Visual polish. Fonts, spacing, colours. Humans see these better than scripts.
- Anything redesigned every sprint. Automating churn buys you maintenance, not confidence.
For a longer treatment of which flows belong in a suite, my article on scenarios to include in test automation walks through the categories with examples.
Your suite roadmap
Write down the five user promises on Tumble Kitchen that pass the Monday morning question, in order of money. Without ever calling it a roadmap, you have already automated most of one: search with an exact price, the sign-in boundary loop, the cart arithmetic, and the feed agreement. The discount boundary joins on Day 16, and it is the biggest of them. The list you write today tells you whether anything is still missing, and, just as useful, what you are deliberately not automating.
The manual side of the same skill
Executing and recording test results is a craft of its own: what status to record when a case half-passes, what evidence to capture, when a failure is worth stopping a run. My Test Run Simulator puts you inside a six-case run against a mock store and coaches you on exactly those calls. Fifteen minutes there sharpens how you read your automated runs too, because the judgment is the same.
Automate the tests whose failure would stop the team on a Monday morning. Everything else waits its turn, or never gets one.
Do this today
Write the five promises, ordered by money, and mark which ones your suite already guards. Then spend fifteen minutes in the simulator. Tomorrow you learn to read everything your suite says back: runs, reports, and traces.