6 test types
Functional, browser/device, content, performance, accessibility, security.
4 × 3 matrix
The pragmatic browser and device coverage for European projects.
7 fields
What a bug report needs so nobody has to ask back.
QA testing is the engine inside the review
Testing verifies against criteria. The review around it adds roles, the client round and the sign-off decision.
Website QA testing answers one question with evidence: does this site meet the quality bar we defined — functionally, visually, on real devices, at real network speeds, for all users? It produces a prioritized bug list, and after fixing and re-testing, a defensible launch decision.
Testing is one part of the bigger website review process: the review adds who checks what, the client round and the documented approval. If you haven’t set up that process yet, start with our website review guide — this page goes deep on the testing engine inside it.
Testing by vibes
“We clicked through it, looked fine”
- Whatever browser the tester happens to use
- Happy path only — nobody types a wrong email on purpose
- Bugs reported as “contact form is broken”
- No re-test after fixes
Testing against a plan
Matrix, unhappy paths, verified fixes
- A defined browser/device matrix per project
- Error states and edge cases tested on purpose
- Bug reports with element, environment and steps
- Every fix verified and regression-checked
What “tested” actually covers
Skip one type and that’s exactly where it breaks. The six together are the definition of done.
Functional testing
Does everything do what it should? Forms, navigation, search, checkout, integrations — every interactive element, every state: success, error, empty.
Cross-browser & device
The same page in Chrome, Safari, Firefox and Edge — and on real phones. Rendering engines disagree exactly where your layout is cleverest.
Content & visual
Final texts, correct data, consistent spacing, sharp images. Not glamorous — but content bugs are the ones clients find first.
Performance
Load time on 4G, image weight, Core Web Vitals. A site that scores green in the office can still crawl on a train.
Accessibility
Contrast, keyboard navigation, alt texts, focus states. Legally required for many, right for everyone — and it catches real usability bugs.
Security & privacy basics
HTTPS everywhere, forms validated server-side, consent before tracking, no secrets in the source. The baseline every project owes its users.
Browsers and devices: the pragmatic minimum
You can’t test everything. You can test what your visitors actually use — and one honest step beyond.
Check your analytics first: the real distribution beats any generic list. Without data, this matrix covers the vast majority of European traffic — four desktop browsers, three physical devices, both orientations. Test the top mobile configuration on a real device, always: emulation gets layout right and touch behavior wrong.
Desktop pass
- Chrome (current) — the majority baseline
- Safari (current) — the layout-engine outlier
- Firefox (current) — forms and font rendering
- Edge (current) — corporate environments
- One pass at 1366×768 — not everyone has your monitor
- Zoom at 125 % and 200 % — accessibility and laptops
Device pass
- Current iPhone with Safari — real device
- Mid-range Android with Chrome — real device
- One tablet, both orientations
- Touch targets 44 px+, nothing under the thumb zone
- Software keyboard doesn’t cover active inputs
- Landscape mode not broken
Pre-launch testing in 6 steps
The order is deliberate: environment before function, function before polish, and verification after every fix.
- 1
Plan the matrix
Decide what gets tested where: which pages, which browsers, which devices, which test types. A matrix of 4 browsers × 3 devices × key pages beats “we clicked around”.
- 2
Test on the real environment
Staging must match production: same server config, real content, real integrations in test mode. Bugs that only exist on production are bugs you shipped.
- 3
Run the functional pass
Every form, link and interactive element — including the unhappy paths: wrong input, double submit, back button, expired session.
- 4
Run the device pass
Real devices for the top configurations, emulation for the rest. Check both orientations, touch targets, and the keyboard covering inputs.
- 5
Performance & accessibility pass
Lighthouse or PageSpeed as the baseline, then a manual check: tab through the page, zoom to 200 %, throttle to 4G. Numbers plus experience.
- 6
Fix, verify, regression-check
Every fix gets verified by the person who reported the bug — and the surrounding area gets a quick regression look. Fixes love breaking neighbors.
The step everyone skips
The bug report that never needs a follow-up question
Half of QA time disappears into asking back. The fix: a report format that captures the context the moment the bug is found.
A usable bug report answers seven questions: where (URL), what exactly (the element), in which environment (device, browser, OS), how to reproduce it (steps), what was expected, what happened instead — and what it looks like (screenshot, or better: a pin on the live page).
The reason most reports miss half of this isn’t laziness — it’s that collecting environment info by hand is tedious. Tools that pin feedback directly to the element capture URL, device, browser and OS automatically, so even a client’s bug report arrives complete without the client knowing what an OS version is.
Bug reports that document themselves
With bepeq, every pinned comment automatically carries the page, element, device, browser and OS. Vague reports get a follow-up question from the Pilot while the reporter is still on the page — and re-testing happens right where the bug was pinned.
Start bepeq for freeClient
“Not sure about the section up top.”
✦ bepeq Pilot asks back
What exactly bothers you: color, image or text?
Hero image brighter, headline higher contrast.
readyRelated guides and checklists
Website review guide
The broader process around testing: roles, client round, documented sign-off.
Website redesign checklist
40 points across 5 phases for relaunch projects specifically.
User acceptance testing
The test after QA: the client verifies against the agreement and accepts.
Bug report template
The 7 fields from this guide as a copyable template.
Common questions about website QA testing
What is website QA testing?
Website QA testing is the systematic check of a website against defined quality criteria before launch or release: functional tests (forms, links, integrations), cross-browser and device tests, content checks, performance, accessibility and security basics. The output is a prioritized bug list — and after fixing and re-testing, a site you can defend shipping.
What’s the difference between QA testing and a website review?
QA testing verifies against technical criteria and is mostly done by the team. A website review is the broader process around it: it includes the client’s perspective, content ownership and a formal sign-off decision. Testing is one engine inside the review process — our website review guide covers how they fit together.
Which browsers and devices should I test on?
A pragmatic minimum for European projects: Chrome, Safari, Firefox and Edge on desktop; one current iPhone (Safari), one mid-range Android (Chrome), one tablet. Check your analytics for the real distribution — and always test the top mobile configuration on a physical device, not just emulation.
What belongs in a good bug report?
Seven things: the page (URL), the exact element, device, browser and OS, steps to reproduce, what was expected versus what happened, and a screenshot or — better — a pin on the live page. A bug report missing the environment info costs a round trip per bug; on a 30-bug list that is a lost week.
Manual or automated testing for agency websites?
For typical marketing and corporate sites: manual, checklist-driven testing wins on cost-benefit — the site changes rarely after launch. Automation pays off for web apps, shops and sites with continuous deployment. Start manual and structured; automate the checks you repeat most once the project justifies it.