Software Testing Checklist: What Belongs on It, Phase by Phase

A software testing checklist is a written list of test conditions a tester works through to cover a release, grouped by the phase of the test process each condition belongs to: planning, analysis, design, implementation, execution, monitoring and completion. The ISTQB Foundation Level syllabus, which names the practice checklist-based testing, rules out the kinds of item that most published checklists are full of: anything a machine can check on its own, anything that is really an entry or exit criterion, and anything too general to check separately.

The full checklist is below, phase by phase. Every line is something a person does and can tick, the lines that get skipped on real projects are marked, and the whole thing is written to be pasted into a ticket.

What is a checklist in software testing?

A checklist is a set of test conditions written in advance, worked through by a tester and ticked as each one is covered. The ISTQB Certified Tester Foundation Level syllabus, version 4.0.1, released on 15 September 2024, puts it this way: "In checklist-based testing, a tester designs, implements, and executes tests to cover test conditions from a checklist." It classes the technique as experience-based, alongside exploratory testing and error guessing, because checklists "can be built based on experience, knowledge about what is important for the user, or an understanding of why and how software fails."

That sourcing is the mechanism. A working checklist is one your team has edited after a defect got out. The syllabus is direct about the maintenance obligation: "Some checklist entries may gradually become less effective over time because the developers will learn to avoid making the same errors. New entries may also need to be added to reflect newly found high severity defects. Therefore, checklists should be regularly updated based on defect analysis." It adds a warning in the same breath, citing Atul Gawande's The Checklist Manifesto: "care should be taken to avoid letting the checklist become too long."

There is a formatting rule with consequences: "Checklist items are often phrased in the form of a question. It should be possible to check each item separately and directly." An item you cannot answer yes or no to on its own is the item everyone ticks without reading.

What are the 7 steps of software testing?

The ISTQB syllabus describes the test process as groups of activities, and it names seven of them: test planning, test monitoring and test control, test analysis, test design, test implementation, test execution, and test completion. That is the honest answer to the question, and it comes with a caveat the syllabus prints alongside the list: "Although many of these activities may appear to follow a logical sequence, they are often implemented iteratively or in parallel."

On a project running two-week iterations, analysis for the next story is happening while execution for the current one is still open, and monitoring runs across all of it.

Analysis answers "what to test?" in measurable coverage terms; design answers "how to test?"; and on implementation the syllabus is specific about the part teams skip: "The test environment is built and verified to be set up correctly." The checklist below hangs concrete items off each of the seven.

The software testing checklist, phase by phase

Copy it, delete what does not apply to your product, and add whatever your last production incident taught you. Items marked often skipped go missing when a date moves.

Planning, before a single test is written

• Write one sentence saying what this release is for and what a failure of it costs.

• Name the test basis item by item, meaning the requirements, tickets, designs, API contracts or regulations the tests derive from, with the version of each.

• List the product and project risks and rank them, so test effort follows the ranking.

• Write the entry criteria, meaning the preconditions that must hold before execution starts. Often skipped.

• Write the exit criteria in the same sitting, mixing measures of thoroughness with binary yes or no criteria, and name the person who may waive one.

• Write down what is out of scope, in the same document.

• List every environment, data set, device and third-party sandbox you need, with an owner's name against each line. Often skipped.

Test analysis, deciding what to test

• Walk the test basis, list the testable features, and turn each into test conditions prioritised against the risk ranking.

• Check each requirement for testability and raise a defect against any you cannot write a pass or fail against. Often skipped, and it is the cheapest defect you will ever file.

• Record traceability from requirement to condition, so coverage can be reported against the basis itself.

• Name the quality characteristics in play beyond function: performance efficiency, compatibility, usability, reliability, security, maintainability, portability, safety.

Test design, deciding how to test

• Elaborate each condition into test cases and coverage items, deriving the case count with a technique such as equivalence partitioning, boundary value analysis, decision tables or state transition testing, and designing the negative cases in the same pass as the positive ones.

• Write the expected result for every case before anything runs. Often skipped, and a case with no expected result passes whatever the software does.

• Define the test data each case needs, including the data that must be absent for the case to be valid.

• Decide which cases will be automated and which stay manual, with the reason written next to each decision.

Test implementation, the environment and the testware

• Build the environment and verify it with a smoke test that fails loudly when the environment is wrong.

• Provision the test data, masking anything from production before it lands where a developer can read it. Often skipped.

• Stand up stubs, drivers, simulators or service virtualisation for any dependency you cannot call for real.

• Obtain third-party sandbox credentials and confirm who renews them. Often skipped.

• Assemble cases into procedures and suites, and order the execution schedule so a run cut short still covers the highest-risk conditions.

• Commit the automated suite to CI and make a red build block a merge.

• Run the suite twice on an untouched build, so you know which failures are the product and which the tooling.

Test execution

• Run to the schedule, log results as you go including passes, and compare each against the expected result recorded at design time.

• Analyse each anomaly for its likely cause before you file it.

• File defect reports carrying the fields a developer needs to reproduce without asking you: unique identifier; title; date observed, organisation and author with their role; test object and environment; context, meaning which case, activity, technique, checklist and data were in play; reproduction steps with logs, dumps or screenshots; expected and actual results; severity; priority; status; references back to the case.

• Confirmation-test every fix by running the tests that failed because of that defect.

• Run an impact analysis before you decide the regression scope. Often skipped.

• Run regression across the environment as well as the object. A certificate rotation or a config push moves behaviour without touching your code.

The non-functional passes

• Performance: agree the load profile in writing first, meaning concurrent users, ramp, duration and think time, then the thresholds. Run to that profile, then past it, and record where it breaks and how it recovers.

• Security: work a named, versioned list. The OWASP Web Security Testing Guide publishes one.

• Accessibility: test against WCAG 2.2 at the conformance level you committed to, and record the level in the report.

• Compatibility: fix the browser, operating system and screen size matrix in writing first, and record what it leaves out.

• Reliability and recovery: kill a dependency mid-transaction and watch what the user sees.

• Install and upgrade: test the upgrade path from the version customers are running today. Often skipped, because the team upgrades from last week's build.

• Data formats and localisation: dates, currency, decimal separators, name lengths, right-to-left text if you ship it.

Monitoring and control, running alongside all of the above

• Compare actual progress against the plan on a fixed cadence, and report coverage as a proportion of the test basis, with the uncovered part named.

• Record each control action and why, so the decision trail survives the release.

• Track the defect backlog by severity, with an age on each open item.

Test completion, the phase that gets cut

• Raise a change request or backlog item for every unresolved defect, so nothing closes by being forgotten.

• Archive or hand over the testware worth keeping, in a format the receiving team can run.

• Shut the test environment down to an agreed state. Often skipped.

• Amend this checklist from the defects that got out, and delete any item that caught nothing in a year.

• Issue the test completion report to the people named in the plan.

Which checklist items get skipped, and what does the skip cost?

Every item marked above is invisible on the day it is skipped and expensive weeks later, which is the exact profile of work that loses an argument with a release date.

Entry criteria. Teams write exit criteria because someone asks what "done" means. Almost nobody writes the preconditions for starting. The ISTQB syllabus states the consequence plainly: "If entry criteria are not met, it is likely that the activity will prove to be more difficult, time-consuming, costly, and riskier." Agile teams call these the Definition of Ready, and they keep a half-specified story out of the sprint.

Environment and test data ownership. Assigning an owner to each dependency prevents a release waiting on a sandbox credential. Putting a person's name against each dependency takes ten minutes and it is the highest-yield line on the planning list. Where the data comes from production, masking it is a legal question as much as a technical one, which puts test data management in week zero.

Impact analysis before regression scoping. The syllabus is explicit that this comes first: "It is advisable first to perform an impact analysis to recognize the extent of the regression testing." Skipping it fails in both directions. Either the team runs everything, which stops being run at all once the suite passes an hour, or it runs whatever it ran last time, which misses the areas the change touched.

The upgrade path, and everything after the release. Teams test from a clean install because that is what their environment gives them, while customers arrive carrying two years of data and a config file written by someone who left. Completion suffers from a simpler problem: nobody is watching. The suite drifts out of sync with the product, and the lessons that would have improved the checklist stay unrecorded.

Why do published testing checklists break their own standard?

The exclusion rule in the ISTQB syllabus is one sentence, and it disqualifies most of what gets published under this search term. Checklists "should not contain items that can be checked automatically, items better suited as entry criteria, exit criteria, or items that are too general".

Hold a typical downloadable checklist against it. "Verify all links work" is a job for a crawler, so a human ticking it spends attention a script could spend. "Code review complete" is an entry criterion. "Ensure the application is user friendly" cannot be checked separately and directly, so everyone ticks it every time.

A checklist attached to a release record absorbs the appearance of rigour without changing the team behaviour.

The repair is mechanical. Move the automatable lines into CI and let the build fail on them. Move the readiness lines into the entry criteria where a gate can enforce them. Split each general line into conditions a person can answer yes or no to on its own, which usually shortens the list, because the vague line was hiding how little it asked for.

What are the 7 pillars of QA?

There is no standard behind that phrase. It shows up in search suggestions and in listicles, each naming a different set, which is the tell.

Two things with the same shape do have a standard behind them. One is the seven groups of test activities set out above. The other is the seven testing principles in the same syllabus: testing shows that defects are present but cannot prove there are none; exhaustive testing is impossible; early testing saves time and money; defects cluster together; tests wear out; testing is context dependent; and the absence-of-defects fallacy.

Clustering and wear-out both change how you write a checklist. On clustering the syllabus cites Enders 1975: "A small number of system components usually contain most of the defects discovered or are responsible for most of the operational failures." Keep the checklist heaviest where your defects have historically been. On wear-out it cites Beizer 1990: "If the same tests are repeated many times, they become increasingly ineffective in detecting new defects." A checklist unchanged in two years is finding less than it did when it was written.

Where does each standard checklist source stop?

Published sources carry most of the load, each covering a different slice.

IEEE 829 is retired. Plenty of testing checklists still send you to the IEEE 829 test plan and test summary report templates. The IEEE Standards Association record for IEEE 829-2008 carries the status "Superseded Standard" and names the replacements: "IEEE 829-2008 is superseded by ISO/IEC/IEEE 29119-1-2013, ISO/IEC/IEEE 29119-2-2013, ISO/IEC/IEEE 29119-3-2013 and ISO/IEC/IEEE 29119-4-2015." A template pack citing IEEE 829 as current was assembled before 2013, or copied from something that was.

Read the shape of the OWASP list before you adopt it. Of the 109 items, 20 sit under input validation and 3 under API testing, a distribution that made sense for the web applications the guide grew up testing. A team whose product is mostly services behind a thin client, adopting the list unchanged as its whole security pass, has covered its API surface with three line items. Take the identifiers, then add conditions for authentication on every endpoint, object-level authorisation, rate limiting and mass assignment, and put the additions through the same exclusion rule. This is where a security testing or API testing specialist earns the fee, because the items worth adding come from watching that class of product fail.

Is there a software testing checklist template in Excel or PDF?

For the security pass, yes, free and maintained. OWASP publishes its testing checklist as a spreadsheet in the project repository, with worksheets for the checklist itself, summary findings, a risk assessment calculator and references. The same repository carries a Markdown version of the table, which is the one to paste straight into a ticket, and a Google Sheets template you can copy into your own Drive. The repository also publishes a SHA-256 digest for the spreadsheet next to the download link, so hash what you download and compare. The served file is 32,555 bytes and hashes to that published digest.

For the other phases, build from the published structure. The ISTQB syllabus supplies the structure free of charge and ISO/IEC/IEEE 29119-3 supplies formal document templates behind a paywall. Neither can supply the part that makes a checklist work, which is the set of items your own product has earned through its own defects. Start from the phase list above, put it wherever your team already works, and add an item every time something reaches production that should not have.

What belongs on a user interface testing checklist?

Interface conditions fail the "check each item separately and directly" test more often than any others, because the tempting phrasing asks for a judgement. Borrow from a published set. The ISTQB syllabus points at Jakob Nielsen's usability heuristics as a checklist supporting a non-functional test type, and some convert into items straight away. Visibility of system status becomes: does every action lasting more than a second show progress, and does every completed action confirm itself. Error prevention becomes: is a destructive action confirmable or reversible, and are inputs constrained so the invalid value cannot be entered at all.

The rest of the items that repay themselves on a web application are the structural ones: keyboard reachability of every interactive control, focus order following reading order, focus visibility against every background it can land on, a validation message naming the field and the fix, state preserved on browser back, and layout integrity at the smallest supported width with the font size increased. Several of those double as accessibility conformance conditions. Run the list across the device and browser matrix fixed during planning. Spacing and colour belong in a design review.

What the checklist looks like on a live engagement

Vervali built and tested a finance-management platform for a UAE company serving small and medium businesses, covering receivables, payables, tracking and reminders across a mobile app and a web application, with manual and automation testing alongside the build. On the client's reported figures, testing time fell by 40% once the repeatable passes were automated, user satisfaction reached 98%, transaction processing efficiency improved by 35%, and the platform met UAE regulatory requirements in full.

The 40% figure is the one worth reading closely. The items that stayed on the human list were the ones needing judgement; the items that came off it went into an automated suite and into the build.

A second engagement covers a wider surface. Vervali worked with an Indian manufacturer running a nationwide dealer and service network on a centralised customer support ticketing system across web and mobile, with automated department routing, SLA management and real-time tracking. The recorded tooling maps onto the phases above almost line by line: Selenium for browser automation, Appium for the mobile client, Postman against REST and SOAP endpoints, OAuth2 flows as their own condition set, Jenkins running the suite on every build, Jira holding the defect reports. The client reported a 70% cut in resolution delays and a 90% increase in visibility and accountability.

Vervali holds ISO/IEC 17025:2017, CMMI Maturity Level 3, ISO 9001:2015 and ISO/IEC 27001. ISO/IEC 17025:2017 covers testing and calibration laboratory competence, so an assessor examines the competence of the people and equipment producing a test result. Further engagements are on the case studies page.

How does a testing checklist become a release gate?

By being wired to the exit criteria. A checklist must be wired to exit criteria to enforce a release gate.

The ISTQB syllabus splits exit criteria into measures of thoroughness and binary criteria, and you want both. Measures of thoroughness are the coverage number, unresolved defect count, defect density and failed case count. Binary criteria are the yes or no ones: planned tests executed, static testing performed, all defects found reported, all regression tests automated. Agile teams call the combined set the Definition of Done.

Write the gate as a short list, each criterion traceable to the phase list, with a threshold and a named owner, and write down what happens when one is missed. That clause decides whether the gate is real. The syllabus allows the honest version: "Running out of time or budget can also be viewed as valid exit criteria", provided "the stakeholders have reviewed and accepted the risk to go live without further testing."

Settle the thresholds before the release, while nobody is under pressure: what severity of open defect blocks a ship, and what proportion of the test basis has to be covered for application testing to count as complete. Deciding those on the night of a release means deciding them in favour of shipping.

When is a testing checklist the wrong tool?

A checklist is a coverage aid for a known surface, and there are situations where it works against you.

When the risk is novel. A checklist encodes what a team already knows fails. A new architecture, a first integration with an unfamiliar payment provider, a migration onto infrastructure nobody has run in production: those carry risks nobody has written down yet. Exploratory testing finds them, and the checklist gets updated afterwards.

When the item can be automated. If a machine can evaluate the condition on every commit, a human ticking it once per release is worse coverage at higher cost. Move it into continuous integration and let the build carry it.

When the answer is a measurement. Performance under load is a measurement with a threshold. Whether a defined transaction mix holds its latency target at a defined concurrency is a performance or load test, and the answer is a number with a threshold beside it. The same goes for scalability and stress behaviour.

When compliance sets the scope. In a regulated context the regulation writes the list, and an internal paraphrase of it will be checked against the original by someone else. Work from the source text and treat compliance testing as its own scope with its own evidence trail.

When nobody owns the outcome. A checklist reports what it found, and acting on the report takes authority a person has to hold. Where nobody can stop a ship on the strength of it, the ticks accumulate and the release goes out anyway.

For a second pair of eyes on the checklist you are about to gate a release with, Vervali's application testing practice covers web, mobile and API surfaces, and the contact page routes to a scoping call.