Test

Someone sends you a build and asks what you think. The weakest answer you can give is that it looks good. Plenty of sites look good, and saying so tells nobody what to change.

A review answers one question: does this build do the job it was given? You already wrote the job down. The brief says what the site must achieve, states its one job in a line, and ends with the checks it has to pass before sign-off. The positioning says what only this business can claim. The art-direction brief, with its recipe, says how it should look and why. Those documents are the standard. Your taste isn't.

Comments like these are feelings about the whole page. None of them can be acted on, and none of them can be argued with, which is the problem. A judgment names one element, quotes the line in the brief, positioning or recipe that it breaks, and says what should change. If you can't find a line to quote, you have two honest options. Find the gap in the brief and fix the brief, or drop the comment.

Do it in this order. Re-read the brief, the positioning and the recipe before you open the build, so you're holding the standard and not a first impression. Go through every page and write down each failure with the line it breaks. Rank them by how much each one gets in the way of the site's one job. Only then write what works. Critique goes first because praise anchors you. Once you've written that the hero is lovely, you start defending it. Don't skip the praise, though. What works, and why it works, is what nobody is allowed to break in the next round.

Here's the finding that matters most in the fictional bakery's review build, on October fourteenth. The brief's first sign-off check asks: is ordering ahead on the first screen? On a phone, it isn't. Here the phone's screen is three seventy-five by six sixty-seven pixels. The photo runs full width, the one Order ahead button starts at seven-thirty, below the screen, and the header folds the order link behind Menu. That breaks the site's one job, so it ranks first. The change keeps Order ahead visible in the phone header on every page, and leaves the photo-first rule from the art direction alone, because that rule is defended. On the sixteenth, the same check runs again on a phone, and it passes.

Then ask each page these questions. Start with the brief's sign-off checks, run exactly as written, on the device they name. Does the page serve the one job? Does it say something only this business could say? Is the decisive move from the art direction still there, and is the recipe followed on the inner pages, where builds usually drift? And can every claim on the page be traced to a source? A review that skips that last question can pass a site that's lying. The review is done when every sign-off check has been run.

Once the failures are listed, ask what would make this remarkable. A remarkable move has to trace back to evidence, like a confirmed claim or a customer's own words, or to intent declared in the brief. The bakery's customers keep writing “worth the queue”, and the positioning is already built on those words. What remarkable never justifies is a claim nobody confirmed, like the founding year the AI invented, lower contrast for the mood, or a skipped check because the client is waiting.

Last step, on every review: remove one thing. Builds collect elements because sites usually have them: a stats strip, a second call to action, a row of icons. Find the element that no line in any of the three documents defends, and cut it. If everything on the page is defended, say so and leave it alone.

If a judgment can't point to a line in the brief, the positioning or the recipe, it's taste. Find the line, or keep it to yourself.

Review notes in a separate document drift away from the page. A note that says fix the header and the colors leaves the builder guessing which header, at which width, and when it’s done.

So review on the live page, in a loop. Pin each note to the element it’s about, and ask for one change per note. Freeze the baseline before anything is fixed. Then, after every round of fixes, sweep the whole build again, and close a note only when that sweep passes.

Here’s the bakery’s review build on a phone, three seventy-five wide. Select the element itself: the Menu button that hides the order link. The note pins to it and records the page, the element and the width, so the builder sees exactly what you saw.

My first draft of that note also asked for the label to read Today’s bread. That’s two changes, so it becomes two notes, the second pinned to the label itself. Each one can now be fixed, checked and closed on its own. The third note goes on an allergens line, a gray that measures three point one to one on the cream background. Three notes, three pins.

Before anyone fixes anything, freeze the baseline. Check that nothing is waiting to be saved, then tag the build as it was reviewed. Then run the sweep on it: every check from the review, on every page, at four widths. Three checks fail, one for each note. Two pass, and they have to keep passing.

The builder sends round one, and at three seventy-five all three notes look fixed. Don’t stop at the notes. Sweep the whole build again, against the baseline. Three checks went from fail to pass. One went the other way: the home page and Today’s bread now have two Order ahead buttons, at every width. The note asked for the order link in the phone header. The fix put a second big button in the header at every width, and the design allows one a page. Nobody checked the desktop, because no note was about the desktop. That’s what the sweep is for.

So the regression becomes a fourth note, pinned to that button. Round two stops folding the header links behind Menu on phones, so Order ahead is a link again and the extra button is gone. Sweep again: every check passes, and nothing that passed before has failed. Only now do the four notes close, each with the date of the sweep that proved it.

One note per change, pinned to its element. Freeze a baseline, re-sweep every round.

The automated scan came back clean. Then you put the mouse away, press Tab, and by the fourth press you've no idea where you are on the page. No scanner would have told you that. W3C is plain about it: evaluation tools can't determine accessibility, they can only assist.

WebAIM points out that many people with motor disabilities rely on a keyboard, and that blind users typically navigate by keyboard, with a screen reader reading the page aloud. So this check is you, using the page with those tools. Three passes on every page template: keyboard, screen reader, then zoom. Each one ends as a line in your QA record.

Set up first, or you'll record your own computer's settings as the site's failures. On a Mac, turn on keyboard navigation in System Settings, and in Safari's advanced settings tick Press Tab to highlight each item on a webpage. That's what lets Tab reach links and buttons. VoiceOver is built in, and Command-F5 turns it on. On Windows, NVDA is free. Write down the browser, the screen reader and their versions, because the record needs them.

Start at the address bar. Tab forward, Shift-Tab back, through the whole page. Enter follows a link, Enter or Space presses a button, arrows move inside radio groups and menus, and Escape should close a dialog. At every stop, ask whether you could reach it, use it and leave it, whether the order makes sense, and whether you can see where you are. On a fictional bakery's homepage, the third Tab lands on the Order button and nothing shows. That fails 2.4.7. Further down, the cookie banner covers the focused Allergens link completely, which fails 2.4.11.

Then the screen reader. Listen first for the page title: it should tell you where you are. WebAIM notes that screen reader users rarely listen to a whole page. They jump by headings, landmarks and links, so you should too. In VoiceOver, VO-U opens the rotor, with lists of headings, links and form controls. In NVDA, H moves to the next heading, D to the next landmark, and NVDA-F7 opens the elements list. The bakery's quantity buttons are announced only as button, and the hero photo as a file name. Both fail.

Last pass. Zoom to two hundred percent and check nothing is lost. Then apply WCAG's four text spacing values together: line height one and a half times the font size, paragraph spacing twice, letter spacing point one two, word spacing point one six. The bakery's menu cards have a fixed height, and the last line of every description vanishes. Then a twelve-eighty window at four hundred percent, which W3C treats as three hundred and twenty pixels: you should only scroll one way. Small targets need twenty-four by twenty-four CSS pixels, unless one of W3C's five exceptions applies.

Be honest about what that was. You're probably a sighted person who started using a screen reader this week. WebAIM warns that a new user can decide everything is broken when the problem is their skill with the tool, and that sighted testers can trust what they see without noticing it wasn't read out. So the record calls it a human check by the creator, names the pairing you used, and its basis is creator declared. User testing means disabled people using the site, and W3C says that finds problems a standards check alone misses.

Here's the bakery's record. One line per check, with the method, the result, what you did and on which templates. Every failure under it names the page, the element and the success criterion, so whoever fixes it can find it. A pass says what it covered, so nobody reads it as more. The commit is there because next week's build is a different site.

Use every template with keys, speech and zoom. Record it as your own check, never as user testing.

You checked the page at desktop, tablet and phone, and all three looked fine. Then someone zooms in to read, or narrows the window, and the order page breaks.

Here's the bakery's order page at the three reference widths: twelve-eighty, seven-sixty-eight and three-seventy-five. All three look fine, and they're good frames for screenshots and review. But people use every width in between and below. Three checks tell you about three points on a line, and nothing about the rest of it.

So keep both, for different jobs. The reference widths stay for screenshots and review. QA sweeps the whole range, down to three hundred and twenty. That number isn't about phones. WCAG's reflow rule uses three-twenty CSS pixels because that's what a twelve-eighty window becomes at four hundred percent zoom.

Use your browser's developer tools, or just drag the window narrower. Start at your widest width and go slowly, watching the page rather than the number. Stop at the first thing that breaks. At three hundred and sixty-two pixels, Morning buns is squeezed onto two lines, a word on each, by the price and the buttons beside it. Write down the width and the element, then find the rule behind it. This one says the name, the price and the buttons share one row, at any width. Three-seventy-five was fine, so no screenshot ever showed it.

Know what you're looking for. The page scrolls sideways. A line holds a word or two. Text spills out of its box. Buttons crowd together. An image stretches, or crops out its subject. Sweep with the real copy at its longest, and sweep up past your widest width too: a paragraph running the full width of a big screen is broken as well.

Here's a break recorded the same way for another fictional client, a garden designer. At one thousand and twelve pixels, the services grid still has three columns, and every title wraps to four lines. The last line is the rule that put it there.

The tempting fix is one more breakpoint at three-sixty-two. It works at that width, for these loaves. Then Morning buns go up to twelve fifty, and the row breaks again at three-seventy-three. So change the rule. When the price and the buttons don't fit beside the name, they move under it, at any width. Then sweep the whole range again, because changing a rule moves things. This time the row holds at every width, all the way down to three-twenty. And update the responsive rules you wrote before the build, so the next page follows the fixed one.

The garden designer's grid got the same treatment. Instead of another breakpoint, the grid holds as many columns as can each be at least eighteen rem wide, and the min with a hundred percent stops a card overflowing on the narrowest screens.

Screenshots at three widths are for review. QA is the whole range. When something breaks, find the rule that produced it and change that.

Run a speed test, fix whatever turns red, and you'll get a faster page this once. On the next project you'll be just as surprised.

There's a better loop, and it starts before any test runs. Predict what will be slow, and write it down. Measure. Compare the two, because the gap between your guess and the result is what you learn from. Then fix the slow thing where it's made, and measure again.

Here's a prediction for the bakery's homepage, on a phone. I think the queue photo at the top is the slow part, and loading will go over the line. The file is four thousand pixels wide and one point three megabytes, and on a phone it's shown three hundred and seventy-five pixels wide. I think nothing will jump, because the photo has its width and height. And there's little to tap on that page. That took two minutes. It's written down, so I can't quietly rewrite it once the results come in.

The three numbers are Google's Core Web Vitals, and Google sets what counts as good. Largest Contentful Paint is loading: two and a half seconds or less. Interaction to Next Paint is how quickly the page answers a tap or a keypress: two hundred milliseconds or less. Cumulative Layout Shift is how much things jump: point one or less. Google judges them at the seventy-fifth percentile of page loads, so most visitors need a good experience, including the ones on old phones.

Now measure. A lab test is one simulated load, so it works before anyone has visited, and it's good at pointing to causes. Here's the bakery's homepage, loaded five times on a phone with the connection and the processor slowed down. Loading takes seven point eight seconds, three times the line, and the largest element is the queue photo. Layout shift is point zero three, under the line. Responsiveness needs someone tapping, so one lab load can't judge it. Try the buttons yourself, on a phone. Real visitors' data covers the last twenty-eight days, and before launch there isn't any. So read the lab result as evidence about causes, not as a grade.

Then compare the guess with the result. The photo, as I guessed, and loading well over the line. Jumping: I guessed none, and the text moved a little when the fonts arrived. It's under the line, but my picture of the page missed it, so it goes in the log. Responsiveness I'll test by hand. And next time, I'll check the fonts first.

Most fixes make the slow thing smaller, or make it arrive after the things that matter. Google's own guides are specific: give images a width and height so their space is reserved, reserve space for anything that arrives late, never lazy-load the main image, and don't let the font hold the text back.

Then fix it where it's made. Every photo on the site goes through one small image helper, and right now it sends out the file that came in. So it was never only the queue photo's problem. Fix it there. Each photo now comes in two widths, eight hundred and sixteen hundred pixels, and the browser picks the one it needs. It keeps its width and height, so the page saves room for it. The hero loads straight away with high priority, and everything else waits until it's needed. Write it once, and no page can forget. Then measure again, against a new guess written first: under two and a half seconds, because the photo now arrives at the size it's shown. Loading now takes half a second. The small jump from the fonts is still there, under the line, and it's logged.

Write the guess down before you run the test. The gap between them is what you learn, and the fix belongs where the slow thing is made.

This redesign looks finished. But a page can look perfect and still send people nowhere. So before anyone sees it, test what it connects to: every link, every form and every outside service, on the review address. And write each result down.

Start with the links. This script reads the page, finds every address on it, asks each one for its answer, and follows any redirects. Twenty-three links. Six jump to a section of the same page, and each section is there. The other seventeen all answer two hundred, which means OK. But a two hundred isn't proof. A video page answers two hundred even when the video doesn't exist. Here's a made-up address: two hundred. So ask the video service itself. All nine talks are there, and the made-up one is refused.

Some links can't be real yet. This is a speculative redesign I made for AllWeb, so the ticket buttons can't sell tickets. Each one says so when you point at it: demo only, not a live link. Nineteen of them, each one labeled. That's honest. A button that quietly goes nowhere isn't.

The page has one form: a sign-up for the program. It's a prototype, and it says so. Send a test address, and it answers: nothing was sent. The check agrees: no request left the page. A prototype can't show you an inbox. So the rest of the form check runs on the practice bakery's order form, on its review build. Send it four ways. Empty: it lists three things to fix. A wrong email: it says what's missing. Offline: not sent, and the details are still there. Right: received. Then open the inbox. One order, from the right test.

Last, outside services: videos, maps, booking, chat, analytics. Each one is another company your page talks to. Open the page in a fresh browser, scroll to the end, and list every address it calls. Here, eighty-two requests, all to the site's own address. No cookies, nothing stored. But one of those requests is a script: the host's visitor count, served from the site's own address. It's still an outside service, so it goes in the record. The talks and the map are plain links, so nothing loads from anyone else until a visitor clicks. For each service, write down what it is, and whether it runs before anyone agrees.

Now write it into the QA record: what you checked, how, and what it found. Links, videos, demo links, each form and outside services, one line each. The pre-send gate can then point at this record instead of at your memory.

Ask every link, send every form, and list every outside call before you send.

You don't need to be a security engineer to catch the common mistakes. Five checks, run on the review address, each written down: the headers the host sends, nothing private in what's served, secure connections everywhere, what the page collects, and who it talks to.

Start with the headers. Ask the address for them, and say in one line what each one does. This one tells browsers to use a secure connection only, for two years. This one stops other sites showing the page inside theirs. This one shares only the domain when a visitor follows a link away. This one switches off the camera, microphone and location. And the content policy lets the page load scripts, styles, fonts and images from its own address, and nowhere else. They're set once, in the project's settings file, so every page gets them.

Next, nothing private in what's served. Download the files the page uses, and search them for key, secret, token and password. One hit. Read it before you panic: it's a comment about design tokens, measured from AllWeb's own campaign art. Then ask for the files that must never be served: the environment file where keys live, the version history, the link to the host, and the brief. Each one answers not found.

Third, a secure connection everywhere. Plain http answers with a permanent redirect to https. Then search the served files for addresses that start with plain http. Two, both labels inside a small drawing in the stylesheet, not requests.

Fourth, what the page collects. One form, the sign-up, and the link check showed it sends nothing yet. The page's own script sends nothing either. The only one that reports anything is the host's visitor count. Last, who the page talks to: nobody else, and the content policy holds it to that.

Write each check into the QA record, with how you ran it. Anything that needs a lawyer or the client goes down as a question, not an answer. Once the sign-up is live, who gets the addresses, and what does the privacy notice say? That's for AllWeb to decide, with someone qualified.

Read what the site sends, search what it serves, and write questions down, not verdicts.

Sending the link is the one step you can't take back. Once the client has it, what's on the page is what they saw, and anything a search engine found is already found.

So before any build leaves you, it goes through a gate. A gate is a fixed checklist, the same every time, that the build has to pass before you send it. The fixed part matters. A list you make up on the day catches what you happen to be worried about that day, and what goes wrong is usually the thing you weren't worried about.

Here's the shape of mine. Each line is a check with a clear pass or fail, and almost every one points at a skill you've already met. Placeholders and claims come from never inventing a fact. The sweep is the responsive lesson. Keyboard and contrast come from accessibility. Then search and indexing, then forms, and a sign-off line that records who ran it and on which commit, so a pass still means something next month. Both of the incidents you've just heard about would have been stopped by a line on this list.

Placeholders get their own step, because your eyes will slide straight past them. You've read that page twenty times. So search for them instead of looking. Run a search across the built site, the files that actually get served, for your placeholder marker and for anything in square brackets. If it returns a single line, the build doesn't go. Fill it with a confirmed fact, or take the sentence out.

Search checks belong in the gate too, and a launch build has its own set. Every page has its own title and description. Each page lives at one address. The sitemap lists the real pages. Structured data states only what you've verified, because schema is a claim like any other. And the noindex you used on review builds is gone, which is an easy one to forget. For the mechanics behind each of these, Google's SEO Starter Guide is the place to learn them.

A review build is the opposite case. It has to stay out of search, and you check that on the live address, not in your code. Two facts make the difference. Google says that if robots.txt blocks a page, its crawler never sees the noindex, and the page can still turn up in results. And on Vercel, preview deployments get a noindex header automatically, but the current production address ending in vercel dot app doesn't. If your review link is a production deployment, nothing has been added for you.

This is the whole check. Ask the live address for its headers and look for the robots header. Then fetch the page itself and look for the robots meta tag. My gate asks for both. Two lines of output, and if either one is missing, the build isn't ready to send.

When a line fails, the build doesn't go. Fix the failure where it started. Then run the whole gate again, from the top. A fix in one place can break something in another, and a gate you only half re-run has stopped being a gate. Then sign it, with the commit it passed on.

You can ask an agent to run every command on this list, and you should, because it's faster and it doesn't get bored on line seven. But the sign-off is yours. Read what each check returned before you tick it. An agent that reports all clear without showing you the output is telling you a story about a pass.

Nothing leaves without passing the same list. Search for placeholders, check noindex on the live address, and send only on a pass.