Practice Landing-Page QA with Codex Computer Use

A landing-page check should finish with reproducible findings, not a message that “everything looks good.” This tutorial uses a fictional, local page with a broken link, a misleading form success message and a layout that needs a narrow-screen check. A corrected version makes it possible to repeat exactly the same tests. The companion kit is a teaching exercise, not an audit of a production business.

Download the QA lab. It contains the Python server, both page versions, tests, a results template and an answer key. The interface is English. No real-browser run is claimed in this article.

Start the local lab

Install Python 3.9 or later, unpack the kit and run this from its folder:

python3 -B server.py --port 8876

The server binds only to 127.0.0.1. Open the printed address in the browser you permit Codex to use. If the port is occupied, select another unused local port and update every URL in your test plan consistently.

Use only addresses ending in @example.test. No real contact details, purchase or external form submission is needed. The baseline is at /, the corrected example at /fixed, and local receiver records at /submissions. Stop the server with Ctrl-C when the exercise is finished.

Give the tester a task, not the answer key

Ask Codex to inspect navigation links, the form and layout at 1440, 390 and 320 CSS pixels. Tell it to preserve evidence, report expected and actual behavior and make no repairs. Keep the fixture’s source and answer key out of the initial test prompt so the observed behavior, rather than a source-code description, drives the report.

This does not create a blind benchmark if the author also built the fixture. Describe the final demonstration as an illustrative controlled test. Do not infer real-world detection rates from a few deliberately constructed faults.

Check links for meaning as well as response

Click the Working guide and Pricing links separately. Record the final page title and destination, then return to the test page. A 404 is a clear failure. A 200 response at an unrelated destination is also a failure when it does not fulfil the link’s promise. The corrected Pricing link should reach the fictional pricing explanation, not merely any route that happens to exist.

Test the form as three cases

Leave the first input empty, use not-an-email for the malformed case and use qa-run1@example.test as a valid synthetic address. Use qa-run2@example.test when repeating the valid case on the corrected page. Open /submissions in a separate tab and note its record count before each case, keeping the original test page open. Use a unique address for the valid case so an older saved record cannot be mistaken for this submission.

For empty and malformed inputs, useful validation feedback should appear and the receiver should not get a new record. For valid input, look for both visible feedback and exactly one matching receiver record. A success message alone does not prove that a lead was stored. Record both layers in the report.

The baseline deliberately displays success without saving anything. That is an expected property of the fixture’s source, not a claim that the browser test has already detected it. Keep that distinction in your own results.

Check narrow layouts at specified dimensions

At each width, inspect the metric cards, navigation, input and submit button. Look for content outside the viewport, obscured text and controls that are hard to reach. Save a screenshot with the actual viewport dimensions. A screenshot without its dimensions is difficult for another tester to reproduce.

A resized desktop browser does not test a physical phone’s browser, keyboard, touch behavior or device performance. Label it as viewport simulation. Restore temporary viewport settings when the test is over.

Turn observations into a useful report

Each finding needs a URL, environment, exact inputs, reproduction steps, expected result, actual result and evidence reference. Separate related symptoms from root causes: accepting empty and malformed input and claiming false success can arise from the same form handler. Do not inflate three symptoms into three independent implementation failures.

Compare the report with the answer key after the first pass. Record missed defects and false alarms as well as correct findings. Repeat the tests on /fixed using new synthetic addresses, then repeat from a fresh task to check whether the written instructions are sufficient without the author’s help.

Results and boundaries

Verified on Python 3.9.6 and Node.js 24.13.0, the local package includes seven in-process Python handler tests and nine JavaScript form simulations. They passed without opening a browser or making network requests. The Python checks cover invalid lengths and JSON, synthetic address validation, record writing, test routes and template substitution. The JavaScript checks execute the form code with fake document and fetch objects.

Run the development checks from the unpacked qa-kit folder:

python3 -B -m unittest discover -s . -p 'test_*.py' -v
node test_form.mjs

Both commands also passed after extracting a fresh copy of the ZIP. These are development checks, not layout tests. They do not prove that Codex finds the injected faults, that the controls render correctly, or that a real browser sends the request. The 1440/390/320 viewport results, screenshots and actual original/corrected browser comparison remain unverified.

This exercise checks a limited set of links, form states and layouts. It does not replace a full accessibility, security, performance or cross-device audit. Its useful output is a repeatable checklist and evidence-backed defect report that someone else can verify before approving a release.

For a programmatic completion check, see the offline Computer Use controller. For browser setup problems, see the permissions guide.