Read-Do and Do-Confirm Checklists: A Complete Guide for ISTQB CTAL-TA Experience-Based Testing
Introduction
Checklist-based testing is one of the main experience-based test techniques in the ISTQB Advanced Level Test Analyst (CTAL-TA) syllabus. Writing a list of items to check is only part of the job. A Test Analyst must also decide how the checklist will be used. The two usage styles are Read-Do and Do-Confirm.
Both terms come from Atul Gawande's The Checklist Manifesto, which drew on checklist practice in aviation and surgery. They have since been applied to software testing and reviews. This guide covers why the distinction matters, what each type is, how each works in practice, and how to answer exam questions on the topic.
1. Why Read-Do and Do-Confirm Checklists Are Important
Checklists catch failures of ineptitude, not ignorance. Most mistakes made by skilled people come from forgetting, distraction or routine, not from a lack of knowledge. Checklists guard against these lapses.
The wrong style undermines the checklist.
- If an experienced tester is forced to read every step of a routine task, they may become frustrated and start skipping the checklist entirely.
- If a novice uses a Do-Confirm list on an unfamiliar, critical task, they may miss steps they never knew about.
It balances flexibility and consistency. Experience-based testing relies on tester skill, but organizations also want repeatability and some coverage measurement. Choosing the right style lets the Test Analyst tune this balance.
It supports risk management. High-risk, safety-critical or rarely performed activities need more structure. Frequent, well-understood activities need less.
It is examinable. CTAL-TA questions often give a scenario (tester experience, task familiarity, criticality, time pressure) and ask which checklist style is most appropriate. Questions may also ask about the benefits and limitations of checklists.
2. What They Are
Read-Do Checklist
The user reads an item, then does it, one item at a time, in sequence. It works like a recipe or a procedure.
Typical features:
- Items are performed in order as they are read.
- The checklist actively guides the work.
- It suits unfamiliar, complex, infrequent or highly critical tasks.
- It suits less experienced testers or people new to the domain or system.
- It is used where the order of steps matters or skipping a step has severe consequences.
Testing examples:
- Setting up a complex test environment for a rarely executed disaster-recovery test.
- A new team member running a security configuration check.
- Following a regulatory compliance verification procedure.
Do-Confirm Checklist
The user first does the work from memory and experience. Then, at a defined pause point, they confirm against the checklist that nothing important was missed.
Typical features:
- Work is done freely and in any order, using the tester's expertise.
- The checklist acts as a safety net and verification step, not a script.
- It suits experienced testers performing familiar, routine tasks.
- It allows creativity and efficiency while still catching omissions.
Testing examples:
- An experienced tester exploring a web form for usability issues, then confirming against a usability heuristics checklist.
- A senior reviewer reading a requirements document, then confirming that standard review items (ambiguity, testability, completeness) were considered.
- A tester running a regression session, then confirming that key areas such as login, payment and reporting were touched.
3. How They Work
Read-Do workflow:
1. Open the checklist before starting.
2. Read item 1.
3. Perform item 1 and record the result.
4. Move to item 2 and repeat until all items are done.
5. Report results and any deviations or defects found.
Do-Confirm workflow:
1. Perform the testing or review activity using knowledge and experience.
2. Stop at the defined pause point, for example the end of a session, before sign-off or before release.
3. Go through the checklist and confirm each item was covered.
4. Perform any item that was missed.
5. Record results.
Characteristics of good checklists (both types):
- Short and focused: Gawande suggests roughly 5 to 9 items per pause point, covering only the critical items most likely to be forgotten (sometimes called killer items).
- Clear, precise wording: items are often phrased as questions that can be answered yes or no, and each should be checkable separately and directly.
- Defined pause points: when the checklist is used, and who uses it.
- Practical layout: fits on one page, with simple language and no clutter.
- Tested and maintained: trialled in real use, updated as the product and defect patterns change, and kept from growing too long.
- No misplaced items: it should not contain items that are better checked automatically, items that belong in entry/exit criteria, or items so general they cannot be checked.
Sources of checklist items:
- Tester experience and knowledge of what matters to users.
- Defect history and defect taxonomies.
- Standards, heuristics and quality characteristics (for example usability heuristics or ISO 25010).
- Common failure causes and lessons learned.
Links to checklist-based testing in general:
- Checklists may be high-level, giving variability, broader coverage and less repeatability, or detailed, giving more repeatability but less variability.
- High-level checklists given to different testers produce different tests. This may find more defects but reduces repeatability.
- Coverage can be measured by the proportion of checklist items covered.
- Checklists provide guidance and some consistency when there is no detailed test basis.
Comparison summary:
- Order: Read-Do is strict and sequential. Do-Confirm is free while working, with confirmation afterwards.
- Best user: Read-Do suits novices or people doing infrequent tasks. Do-Confirm suits experienced practitioners.
- Task type: Read-Do suits complex, critical, unfamiliar or order-dependent tasks. Do-Confirm suits routine, familiar tasks.
- Role of checklist: In Read-Do it guides the work. In Do-Confirm it verifies the work.
- Flexibility and creativity: low for Read-Do, high for Do-Confirm.
- Repeatability: higher for Read-Do, lower for Do-Confirm.
- Main risk: Read-Do can feel tedious and limits exploration. With Do-Confirm, the tester may skip the confirmation step or overlook unfamiliar areas.
4. Exam Tips: Answering Questions on Read-Do and Do-Confirm Checklists
Tip 1: Find the key scenario clues.
- Words such as new tester, junior, unfamiliar, rarely performed, safety-critical, regulated, sequence matters point to Read-Do.
- Words such as experienced, senior, routine, familiar, frequently performed, wants flexibility, exploratory session point to Do-Confirm.
Tip 2: Remember the order of verbs. The name tells you the order. Read then Do means the checklist comes first. Do then Confirm means the work comes first and the checklist comes second.
Tip 3: Watch for reversed definitions. A common distractor describes Do-Confirm as reading each step before performing it, or Read-Do as checking afterwards. Eliminate these options.
Tip 4: Know the pause point concept. Do-Confirm depends on a defined pause point where the work stops and is checked. If an option mentions confirming at the end of a session or before sign-off, it describes Do-Confirm.
Tip 5: Know good checklist practice. Correct answers usually favour checklists that are short, precise, focused on critical items, regularly updated and tested in practice. Treat options that recommend very long, exhaustive checklists covering everything with suspicion.
Tip 6: Connect the style to the trade-off.
- Read-Do: more consistency and repeatability, less creativity.
- Do-Confirm: more efficiency and use of expertise, at the risk of missing things if confirmation is skipped.
Tip 7: Do not confuse checklists with test scripts. A Read-Do checklist is sequential but is still not a detailed test case with expected results for every step. Checklists remain an experience-based technique and depend on tester knowledge.
Tip 8: Recall where checklists fit. They work well when specifications are poor or missing, for non-functional areas such as usability, for reviews, and alongside exploratory testing. Their coverage is measured by checklist items covered.
Tip 9: Eliminate absolutes. Options claiming that checklists guarantee full coverage, eliminate the need for experience or never need updating are almost always wrong.
Tip 10: Practice question pattern.
Example: A senior tester with five years on the product regularly performs a smoke test after each build. The manager wants to keep the tester's efficiency but make sure critical areas are never forgotten. Which checklist approach is best?
Answer: Do-Confirm. The tester is experienced and the task is routine. The checklist acts as a final safety net at a pause point without slowing the work.
Example: A newly hired tester must perform a quarterly backup-and-restore verification in which steps must happen in a strict sequence. Which approach is best?
Answer: Read-Do. The tester is inexperienced, the task is infrequent and critical, and the order of steps matters.
5. Key Takeaways
- Read-Do: read an item, do it, then go to the next. It guides novices through unfamiliar or critical, order-dependent tasks.
- Do-Confirm: do the work from experience, then confirm at a pause point. It verifies the work of experts on familiar tasks.
- Good checklists are short, clear, focused on critical items, have defined pause points, and are tested and maintained.
- In the exam, match tester experience, task familiarity and criticality to the checklist style, and watch for reversed definitions and absolute claims.
