Error Guessing and Checklists

Why error guessing works

Developers are smart, but they build features under time pressure, usually testing with “normal” data on a fast connection with every permission granted. The same blind spots appear again and again:

• Assumptions about input: a name has letters, an amount is positive, a date exists every year.
• Assumptions about the environment: the network is fast, the user said yes to permissions, the app stays in the foreground.
• Assumptions about order: the user does step 1, then step 2, once, and doesn’t come back later.

Every one of these assumptions is a place to guess. And because the blind spots are so common, a short list of guesses finds a surprising number of real bugs.

The typical defect list, in detail

Text input

• Empty: nothing at all. Does Save stay disabled? Is there a clear message?
• Whitespace only: five spaces look empty to people but not to a character count. Leading and trailing spaces ("Mia ") break logins and comparisons.
• Very long: a 500-character name, a pasted paragraph. Is it limited, or does it overflow layouts and databases?
• Special characters: apostrophes (O'Neil), quotes, ampersands, slashes, < and >. They can be shown as O\'Neil, break searches, or reveal that input is treated as code (a hint of XSS or SQL injection).
• Emoji and other scripts: many emoji are made of several characters joined together. Shortening text can cut them in half and leave a � box. Also try right-to-left text, like Arabic.

Numbers and amounts

• Zero: a €0 transfer, 0 items, 0 minutes. Often allowed by accident.
• Negative: -50 in an amount field can make money flow the wrong way.
• Decimals: too many (0.001), none where expected, and the user’s own format (1.250,50 in Germany means one thousand two hundred fifty euros and fifty cents).
• Odd notation: 1e3, +5, ٣ (an Arabic-Indic digit). Generic parsers accept surprising things.
• Huge values: 999999999, which may overflow or break the layout.

Dates and time

• Leap day: 29 February exists only in leap years. Birthdays, anniversaries and “same day next year” logic often break.
• Time zones: the server’s time vs the user’s time. A voucher “at 9:00” might arrive at 18:00 abroad. See time zoneTime zoneThe local time of a region. Bugs appear when apps mix up the user's time zone with the server's.Open in glossary →.
• Daylight saving time: one night has 23 hours, another 25. Recurring alarms and “every 24 hours” logic drift. See Daylight saving time (DST)Daylight saving time (DST)Moving clocks forward in spring and back in autumn, creating a skipped hour and a repeated hour.Open in glossary →.
• Midnight and month ends: 23:59 → 00:00, 31 January + 1 month, 31 December → 1 January.
• Formats: 03/04 is 3 April in most of Europe and March 4 in the US.

Duplicates

Do the same thing twice and see if the app assumes uniqueness: register with an email that already exists, add the same address twice, upload the same photo again, invite a friend who’s already a member. Sometimes duplicates should be allowed (two people named Sam), sometimes not. Either way, the app should behave on purpose.

Interrupted actions

Start something and don’t finish it normally: lock the phone halfway through an upload, take a call during payment, switch to your email app to copy a code, close the browser tab, lose the connection mid-request. Then come back. Is the action finished, safely canceled, or stuck in between? See interruptions.

Permissions denied

Developers almost always test with permissions granted. Deny the camera, photos, location, notifications or contacts, and also revoke a permission later in the system Settings. Does the app explain why it needs it and offer a way to Settings, or does it show a black screen? See app permissions.

Slow and flaky networks

Throttle the connection (Chrome DevTools presets “Fast 4G”, “Slow 4G” and “3G”, or the iOS Network Link Conditioner), switch from Wi-Fi to mobile data, or lose the signal in the middle. Look for misleading messages (“File too large” for a timeout), missing loading states and actions that never finish. See network conditions.

Fault attacks

A fault attackFault attackA planned, systematic form of error guessing: list likely failures, then design tests to provoke each one.Open in glossary → turns guessing into a method:

The idea was popularized by James Whittaker’s book How to Break Software (2002), which describes “attacks” through the user interface (inputs, outputs, stored data, calculations) and through the system’s other interfaces, like the file system and the network. ISTQB describes fault attacks as a methodical approach to error guessing.

The difference from plain guessing is small but important: an attack list is written down, so it can be reviewed, shared and improved, and you can tell what you did and didn’t try.

Building and maintaining your own checklist

A checklist is the memory of error guessing. Here’s how to build a useful one.

Public lists help too. The “Big List of Naughty Strings” on GitHub, for example, collects text inputs that have broken real software. Use such lists as inspiration, then keep only what fits your product.

How it complements systematic techniques

A typical order: cover the spec systematically first, so you know the basics work and can report coverage. Then run a timeboxed error-guessing session, often as part of an exploratory session. Don’t skip the systematic part because guessing “feels” more productive: guessing alone leaves holes nobody can see.

Reporting bugs found by guessing

Developers sometimes push back: “Nobody would type 1e3.” Make the report about impact, not the trick:

• Show a realistic user. “A customer in Germany types 1.250,50 and the app sends €1.25” is more convincing than “comma input not supported”.
• Name the risk. Money moving the wrong way, data lost, a security hint (input rendered as HTML).
• Give severity honestly. An emoji split in a leaderboard is minor. A negative transfer that increases the sender’s balance is critical.

See writing bug reports and severity vs priority.