Learning Objectives
By the end of this lesson you will be able to:
- Describe the characteristics of an effective checklist item
- Build a basic anti-patterns checklist organized by category
- Explain how to maintain and evolve the checklist over time
What Makes a Good Checklist Item?
Not all checklist items are equal. The best items are:
Actionable — they tell you exactly what to do, not just what to think about.
- Bad: "Check edge cases"
- Good: "Submit form with quantity = 0; expect validation error"
Specific — they name a concrete input value or scenario.
- Bad: "Try invalid inputs"
- Good: "Try field value = whitespace only (e.g., 4 spaces)"
Falsifiable — the test either passes or fails; there is no ambiguity.
- Bad: "Check that the logic seems correct"
- Good: "Submit with emailOnly=true, phoneOnly=false; expect acceptance"
Categorized — grouped by the type of mistake they catch, so you can quickly select the relevant categories for each feature.
A Starter Checklist Structure
Category 1: Input Validation
- [ ] Empty string (
"") in every required field - [ ] Whitespace-only string in every text field
- [ ] Value = 0 in every numeric field (test both "zero is valid" and "zero means empty")
- [ ] Minimum boundary value (e.g., min=1 → test 1, 0, -1)
- [ ] Maximum boundary value (e.g., max=100 → test 100, 101, 99)
- [ ] Non-integer in an integer field (e.g., "1.5", "abc")
Category 2: Logical Conditions
- [ ] Each condition in a compound AND: test with only that condition false
- [ ] Each condition in a compound OR: test with only that condition true
- [ ] Boolean field = false when most tests use true (and vice versa)
- [ ] Exact boundary of a ">" check (to catch ">" vs ">=" bug)
Category 3: Enumerated Values
- [ ] Each valid enum value individually
- [ ] An invalid/unexpected enum value (what does the system do with "UNKNOWN_STATUS"?)
- [ ] Empty/null enum value
Category 4: State Dependencies
- [ ] Attempt an action on an object in a state that doesn't normally allow it
- [ ] Submit the same form/action twice in quick succession (double-submit)
- [ ] Submit after a session timeout
Category 5: Multi-Field Interaction
- [ ] Two mutually exclusive options both selected
- [ ] Neither option selected when at least one is required
- [ ] Dependent field submitted without its prerequisite
Applying the Checklist
Use the checklist as a pre-test-design step: before writing test cases for a new feature, scan the categories and identify which apply. Mark the relevant items. Then write specific test cases for each marked item, tailored to the feature's actual field names and business rules.
This takes 5–10 minutes and consistently surfaces test cases that pure specification analysis would miss.
Keeping It Alive
Your checklist should grow with you. After every significant bug you find:
- Classify it by category
- If no category matches, create one
- Add the specific trigger pattern as a new item (or refine an existing one)
A checklist with 50 well-curated items is a professional asset. It makes you faster, more consistent, and harder to fool than any system you haven't seen before.
Pro Tip: Share your checklist with your team. When a team member finds a new bug type, it goes into the shared checklist. After six months, the team has collective experience encoded in a reusable artifact — far more valuable than individual heroics.
Summary
An anti-patterns checklist is the codification of professional experience. It starts as a taxonomy (this lesson), grows through practice (every bug you find), and becomes a powerful tool for approaching any new feature. With this lesson, you have completed Module 6 — apply it all in the Trick Form practice challenge ahead.