Module 7 · Test design techniques

Checklist-Based Testing

By the Mutqan Soft QA team · · 18 min · Intermediate

Checklist-based testing is an experience-based test technique: you design, implement and execute tests to cover the items of a checklist. Each item names something to check — a requirement, an interface property, a quality characteristic or a known weak spot — and the tester decides how to check it. For example, a web form checklist may ask "Is every required field marked before the user submits?"; on a new sign-up form, the tester turns that item into a few quick checks.

In the lesson on error guessing you used experience to predict specific failures and attack them. A checklist turns experience into agreed test conditions: a reviewed, shared list of points that every tester covers, whoever tests.

Why it matters

Many changes are tested without detailed test cases: the specification is thin, the change is small or time is short. Without structure, the result depends on who tests and what they remember, and known problems escape again. A checklist gives such testing a minimum floor and some consistency between testers.

It is also a record: "26 items in scope, 24 passed, 2 failed" tells the team what was covered, which "I tested the form" never does. Because the list grows from real defects, it carries the team’s lessons to new colleagues.

A checklist as the test basis

The ISTQB Foundation syllabus v4.0 groups checklist-based testing with error guessing and exploratory testing as experience-based techniques. When you test with a checklist, it acts as your test basis: each item is a test condition, and your tests exist to cover those conditions.

Detail changes how the technique behaves. A high-level item such as "Are error messages helpful?" leaves room for judgement: two testers will do different things, which may widen coverage but makes the testing less repeatable. A detailed item behaves almost like a short test case. Items are built from experience, from what matters to users and from knowing how software fails:

  • Defect history — problems that reached users or were costly to fix.
  • Published heuristics and standards — Jakob Nielsen’s 10 usability heuristics are a well-known high-level usability checklist; accessibility checklists are often built from the WCAG 2.2 success criteria.
  • Team conventions — supported browsers and languages, date and number formats.
  • Quality characteristics — prompts for non-functional testing such as security, performance and compatibility.

Writing good checklist items

A tester must be able to check each item separately and directly, and record a clear result, so many teams phrase items as questions where "yes" means pass. The syllabus also names what does not belong: items that can be checked automatically, items better suited as entry or exit criteria, and items that are too general.

  • One condition per item. "Errors are shown and translated" is two items; if only the translation is wrong, one tick cannot say so. Several inputs may test the same condition, as in FRM-07 below; two different expected results may not share an item.
  • Observable and specific. "Check that form validation works" names no visible result; "After a rejected submit, does the form keep what the user typed, except the password?" does.
  • Scoped. Say where the item applies, such as every form, so the tester knows when to record "not applicable".
  • Not something a tool can check. If a linter (a program that checks code against rules) or an automated test can check it, leave it to the tool rather than the manual list.
  • Not a criterion. "Build deployed to the test environment" is an entry criterion and belongs in the test plan.
  • Traceable. Give each item an id and, when it came from a defect, the defect id — FRM-07 cites DEF-1184 — so later readers know why it exists.
The weak item Check that form validation works rewritten as FRM-07: an id, a scope, one setup, a yes-or-no check anyone can observe, and the defect the item came from.

Weak item

Check that Part 2:form Part 4:validation works.

One item written to replace it

Part 1:FRM-07 Part 2:[All forms] Part 3:Required field left empty, then Submit: Part 4:is an error shown next to that field, naming it? Part 5:Source: DEF-1184

  1. 1IdLets results, defect reports and later versions of the list point to exactly this item.missing in the weak item
  2. 2ScopeWhere the item applies, so the tester knows when to record “not applicable”. form alone does not say which forms.
  3. 3Setup: one conditionThe single situation the tester creates. Validation covers many rules; this item covers one.missing in the weak item
  4. 4The check: a yes-or-no questionSomething the tester can see; “yes” means pass. works names no result anyone can observe.
  5. 5SourceThe defect the item came from: why it exists, and what to look at before retiring it.missing in the weak item

Worked example: testing a sign-up form with a checklist

A team keeps a web form checklist, now at version 7. A new sign-up form asks for name, mobile number, email and password, plus a box to accept the terms. The checklist does not replace the feature’s own tests: the password rule, 12 to 64 characters, still needs boundary value analysis.

On build 2.14.0 the tester marks which items apply, covers each with a few quick checks and records the result:

  • FRM-02 Is every required field marked before the user submits? Pass.
  • FRM-05 Do name fields accept Arabic and Latin letters, spaces and hyphens? Fail: a name in Arabic letters was rejected; DEF-1302 records the exact input.
  • FRM-07 Required field left empty, then Submit: is an error shown next to that field, naming it? Pass, after five quick tests, one per required field, including the terms box.
  • FRM-09 After a rejected submit, is everything typed kept except the password? Fail: when the email was already registered, the form also cleared the mobile number; DEF-1303.
  • FRM-16 Is the size limit of every upload enforced with a clear message? Not applicable: there is no upload field. Recording N/A shows the item was considered, not forgotten.

Try it: Validation Test Generator Try it: Negative Test Generator

Keeping the checklist current

The syllabus notes that items lose their effect as developers learn to avoid the errors they target, and that newly found high-severity defects (those with a large impact on the product or its users) may call for new items. Update checklists regularly from defect analysis, but keep them from growing too long.

Treat the checklist as testware with an owner and a version: name the version in every test report, compare old and new text before publishing a change, and review the list at a fixed moment, such as each release retrospective.

  • Add an item when a defect it could have caught escapes to production or is found late with a high severity, such as Critical or Major; record that defect id as its source.
  • Rewrite any item that two testers read differently: that is a defect in the checklist.
  • Retire items that an automated check now covers or that have not failed for a long time — after asking whether the lesson was learned or the item is never really checked.
  • When a full pass no longer fits the time available, split the list by area, such as forms, lists and payments, instead of letting testers skim.

Try it: Text Diff

Common mistakes

  • Items so general, such as "Check the UI", that two testers do different things and neither can say whether the item passed.
  • Several conditions in one item, so a partial failure is recorded as a plain pass or fail.
  • Ticking items without noting the build, the data and what was actually checked.
  • Treating the checklist as the whole test: the feature’s own rules still need equivalence partitioning and boundary value analysis.
  • Letting the list only grow, with no owner, no version and items nobody can explain.

The QA perspective

Checklists earn their place where similar things are tested often: every new form, every release candidate, every accessibility review. A senior tester or the test lead usually owns the list, and developers and designers contribute items. Agree on the result values — pass, fail, not applicable, not run — and record the build, the checklist version and the defect id of each failed item.

When you use someone else’s checklist, ask where each item comes from, whether it applies to this feature and what counts as a pass. When you find a defect the list would have caught, propose a new item in the defect report or the retrospective.

Practice exercise

Rewrite a weak checklist and test with it

Your task

A colleague wrote the checklist below for the search page of an online bookshop. Rewrite it so that every item is specific, observable and checkable on its own, remove what does not belong, and give each item an id and a scope.

Then describe the concrete checks you would run for two of your items.

Material
Search page checklist

1. Search works.
2. Results are correct, fast and sorted properly.
3. Check search with special characters.
4. Unit tests for the search service pass.
5. No console errors (the automated browser tests in CI already fail on them).
6. UI looks good.
Steps
  1. Decide for each item: rewrite, split or remove, and why.
  2. Phrase the kept items as yes-or-no questions about something observable.
  3. Add an id and a scope to every item.
  4. For two items, list the checks and what you would record.
Show the model answer
Model answer

Item 1 is too general: rewrite it as an observable check (SRCH-01). Split item 2: "correct" is covered by SRCH-01, "sorted" becomes SRCH-02, and "fast" needs an agreed limit or goes to performance testing. Item 3 names neither the characters nor the expected result: rewrite it (SRCH-03). Remove item 4 (an entry criterion, not a test condition) and item 5 (an automated check covers it). Item 6 is a matter of taste: replace it with observable items such as SRCH-04.

A possible rewrite: SRCH-01 [Search box] Does searching for an exact catalogue title list that book on the first results page? SRCH-02 [Results] With "Price: low to high" selected, is each price lower than or equal to the next, across pages too? SRCH-03 [Search box] Do terms with an apostrophe, a hyphen or Arabic letters return matching books without an error page? SRCH-04 [Results] At 200% browser zoom, are all titles and prices still fully visible?

Checks for SRCH-02: on a search with at least 25 results, choose "Price: low to high", compare the prices down page 1 and onto page 2, and record Pass or Fail with the build number. For SRCH-03: search for O'Brien, e-book and رواية one at a time, recording the exact term with any Fail.

Frequently asked questions

How is checklist-based testing different from error guessing?

Error guessing starts from a prediction: each test targets a specific error, defect or failure you expect, often taken from a fault list. Checklist-based testing works from a written, shared list of test conditions, which can include requirements, interface properties and quality characteristics as well as known weak spots; an item says what to check, not which failure to expect. Fault-list entries that keep finding defects often become checklist items.

Is a checklist the same as a set of test cases?

No. A test case states preconditions, inputs, steps and an expected result. A checklist item names a condition to check and leaves the exact steps to the tester. Checklists are therefore faster to write and maintain and allow more variation between testers, which can widen coverage but lowers repeatability. Where a check must be repeated exactly, as for a high-risk rule, write a test case.

How long should a checklist be?

Long enough to cover the risks it is meant for, and short enough to be used in full in the time available. No standard sets a number. If testers start skimming or skipping items, split the list by area or retire items that no longer find problems.

Can I start from a checklist generated by an AI tool?

As a draft, yes: the AI QA Checklist Generator suggests items for a feature. Review every item against the rules in this lesson — one condition, observable, scoped, not something a tool can check — and remove the generic ones before you test with it. The value of a checklist comes from that review and from your team’s own defect history.

References

Tools

Practise with Mutqan tools

Validation Test Generator

Generate validation test cases for form fields: required, format, length, range, pattern and cross-field rules.

Test Design

Negative Test Generator

Generate negative test cases for form fields and APIs: empty, null, wrong type, too long, injection, invalid format.

Test Design

Text Diff

Compare two texts line by line or word by word and highlight differences.

Formatting

AI QA Checklist Generator

Generate a tailored QA checklist (functional, UI, API, security, performance, accessibility, release) for any feature with Mutqan AI.

Test Generation AI

Go deeper

Your progress on this topic

Part of the QA Roadmap

Before this topic