Free website QA tools

These tools exist because the dull parts of QA are where testing breaks down. A checklist that lives in someone's head gets skipped under pressure. A bug report without steps is hard to act on. Test cases written differently by three people cannot be compared. The tools give each of those jobs a fixed shape, then let you export the result in a plain format that works anywhere.

• QA checklistA step-by-step pre-launch checklist you can tick off and export as text.Read
• Test case builderWrite test cases in a consistent format and save them as CSV.Read
• Bug report generatorTurn a problem into a report a developer can reproduce.Read
• Launch readiness plannerList your release gates and see what still blocks launch.Read

How the tools handle your data

Each tool is a page with a form and a small script. When you press a button, the script reads the form, builds the output on your device, and shows it on the page. There is no server call, no account and no tracking of what you enter. The downloads are generated in the browser too, as plain text, Markdown or CSV files.

That design has one consequence worth knowing: nothing is saved between visits. If you close or reload the tab, the form empties. Export or copy the output when you finish a session.

Which tool to use when

• Planning a launch. Start with the launch readiness planner to list the release gates and see what still blocks go-live. Use the QA checklist to work through the checks behind each gate.
• Preparing structured testing. Use the test case builder to write the cases before anyone starts clicking, so that a pass means the same thing to everyone.
• Reporting a problem. Use the bug report generator whenever you find something wrong, whether you are a tester, a site owner or a member of the public trying to help.

Using the tools without JavaScript

The tools need JavaScript to tick, build and export. If it is switched off, each tool page shows the same content as a plain list or template you can print or copy by hand. The checks, fields and gates are written into the page itself, not hidden inside the script.

Accessibility of the tools

The tools are built to work with a keyboard alone, with visible labels on every field, error messages that list each problem and link to the field, and results that move keyboard focus to the output when they appear. The site's accessibility statement records what testing has been done on them and what has not yet been done.

What the tools are not

They are aids for people doing QA, not automated testers. None of them visits your website, scans pages or measures anything. A ticked checklist records that someone said a check was done; it does not prove the check was done well. The value comes from the discipline of writing things down in a consistent way, which is also the habit that makes outside testing quicker and cheaper when you do bring someone in.

A small workflow using all four tools

The tools are designed to fit together. On a small launch, one person can run the whole loop:

1. List the gates Open the launch readiness planner, set every gate to its true status, and download the plan.
2. Write the cases Use the test case builder for the key flows, such as enquiries, bookings or checkout. Download the CSV and add a result column as you go.
3. Work the checklist Go through the QA checklist group by group, ticking only what has been done on the site that will go live.
4. Report every failure When a case or a check fails, write it up with the bug report generator and send it to whoever will fix it.
5. Update the plan As fixes are retested, update the gate statuses in the planner and download a fresh plan before the launch decision.

The four exports together form a simple test record: what the gates were, what was tested, what failed, and what the final status was.

What we will and will not add

Tool suggestions are welcome, but some limits are deliberate. The tools will not store data on a server, require an account, or connect to your website. They will not produce scores that suggest more certainty than the inputs support. Within those limits, extra fields, checks and export formats are all fair requests.

Printing and sharing the results

Every export is plain text, Markdown or CSV, chosen because those formats open anywhere and survive being pasted into an email, a chat message, an issue tracker or a document. Plain text prints cleanly. CSV opens in any spreadsheet program. Markdown displays as formatted text in issue trackers that support it and as readable plain text everywhere else. None of the exports includes anything you did not type, apart from the date and a line saying which tool produced it.

Feedback

If a tool gets something wrong, or you would like a field or a check added, write to us. We read every message, and changes are noted on the tool page with the date.