Website QA checklist for one important workflow

Set the scope before you click

Pick a clear start and finish: “enter two amounts and read the total,” “find a product with two filters,” or “complete a test signup.” Write down what should happen, not just which page to open.

• Record the URL, date, browser version and desktop viewport size
• Use made-up inputs with a result you can check by hand
• Agree which actions are safe. Use an authorized test environment for submissions
• Stop before real purchases, messages, account changes or deletion unless explicitly authorized

Keep credentials, personal data and private URLs out of public reports. A check you could not perform is blocked or not tested, not passed.

12 checks, with an observable result

Mark each case Passed, Failed, Blocked or Not tested. Skip cases that do not apply, and record why. A pass only describes the case and environment you actually checked.

1. Start fresh

   Try: Open the starting URL in a fresh tab. Record the browser, viewport and default state.

   Look for: The page explains what to do and starts without an unexplained error.

2. Complete the main path

   Try: Use synthetic, valid inputs and follow the intended sequence once.

   Look for: The result matches a manually checked example; success is visible.

3. Leave required inputs empty

   Try: Clear each required field, then try to continue.

   Look for: An understandable message identifies the missing input; no stale success remains.

4. Try invalid input

   Try: Try a wrong format and values just outside the documented limits.

   Look for: The page explains the accepted format or range instead of producing a misleading result.

5. Check boundaries

   Try: Try the minimum, maximum and one value on either side where limits exist.

   Look for: Accepted and rejected values match the stated rules.

6. Change a previous answer

   Try: After a result appears, edit an input and run the workflow again.

   Look for: The new result uses the new input and does not show outdated details.

7. Repeat an action

   Try: Click a safe local action twice. For submissions, use only an authorized test environment.

   Look for: The interface stays usable; a test submission does not create unintended duplicates.

8. Cancel and restart

   Try: Open a dialog or picker, cancel it, then open it again.

   Look for: The original screen remains usable and the second attempt works.

9. Use Back and Forward

   Try: Move through the workflow, use browser Back, then Forward.

   Look for: The visible step and URL agree; restored or cleared inputs behave predictably.

10. Refresh at a useful point

    Try: Refresh after entering inputs or reaching a result, when safe.

    Look for: The page recovers clearly and does not imply an unsaved action completed.

11. Use the keyboard

    Try: Tab through the workflow and activate controls with their expected keys.

    Look for: Focus is visible, order is logical and you can leave dialogs. This is a spot check, not an accessibility audit.

12. Check a narrow viewport

    Try: Resize the desktop browser and repeat the critical path.

    Look for: Text, errors and controls remain usable without clipped actions. This is not a real-device mobile test.

Copy this report outline

Keep findings separate from coverage so that “no bug found” does not imply everything was tested.

Workflow and expected outcome:
Starting URL / build:
Date / browser version / desktop viewport:
Authorized actions and synthetic test inputs:

Case | Passed / Failed / Blocked / Not tested | Evidence

Finding title:
Starting state:
Steps to reproduce:
Expected result:
Observed result:
Impact and proposed severity:
Sanitized evidence:
Retest result:

Untested paths and access blockers:
Questions requiring the team's decision: