CI-Ready QA: The Five Checks Every PR Needs Before Merge

APR 17, 2026 - Written by Yves SoeteBlacksight LLC — QA scanning + CI/CD gating in one tool atkuality.io

Most teams ship their first CI pipeline with a single gate: unit tests pass. That works until the first time a green build deploys a broken checkout page, a layout that collapses on mobile, or a form that submits credentials over HTTP. Unit tests verified the logic was correct. Nobody verified the product was correct. The gap between "code works" and "product works" is exactly the space that CI-integrated QA fills. This post covers the five checks that close that gap and how to wire them into your pipeline without turning every PR into a 30-minute build.

The five-layer model

A production-ready PR pipeline runs five types of checks, each catching a different class of bug:

1. Unit and integration tests — logic correctness. Your existing test suite. These catch regressions in business rules, data transformations, and API contracts. Every team has these or is building toward them.

2. Accessibility scanning — legal and usability compliance. axe-core running against rendered pages, catching missing labels, contrast failures, broken ARIA, and keyboard traps. These prevent the kind of regressions that generate demand letters.

3. Performance budgets — user experience thresholds. Lighthouse CI or WebPageTest enforcing limits on LCP, CLS, INP, and total bundle size. A PR that adds 400KB of JavaScript or introduces a layout shift on the hero section gets caught before merge.

4. Security headers and vulnerability scanning — attack surface management. HTTP header audits (CSP, HSTS, X-Frame-Options), dependency vulnerability checks (npm audit, pip-audit), and form security validation (CSRF tokens, HTTPS submission). These catch the configuration regressions that penetration testers find six months later.

5. Visual and functional smoke tests — product correctness. Playwright or Cypress running against a preview deployment, verifying that critical user flows (signup, login, checkout, settings) actually work end-to-end with real browser rendering.

Each layer is independent and runs in parallel. A typical five-layer pipeline adds 2-4 minutes to PR time, with all five checks running concurrently. The key is that no single layer is sufficient. Unit tests don't catch visual regressions. Performance checks don't catch broken forms. Accessibility scans don't catch slow pages. It's the combination that provides coverage.

The preview deployment problem

Three of the five checks (accessibility, performance, smoke tests) need a running application to test against. This means your pipeline needs a preview deployment — a temporary environment that reflects the PR's changes.

If you're on Vercel or Netlify, you get this free with every PR. If you're self-hosting, you need either a Docker-based preview environment (spin up the app in a container, run tests, tear down) or a shared staging server that pulls the PR branch. The Docker approach is cleaner because environments don't leak state between PRs.

The pattern: PR opens, GitHub Action builds a Docker image from the PR branch, starts it with docker-compose (app + database with seed data), runs the four browser-facing checks against localhost, then tears everything down. Total infrastructure cost: zero beyond the CI runner.

Parallelism and build time

The most common mistake is running checks sequentially. A pipeline that runs unit tests (3 min), then accessibility (1 min), then performance (2 min), then security (1 min), then smoke tests (3 min) takes 10 minutes. The same pipeline running all five in parallel takes 3 minutes — gated on the slowest check.

GitHub Actions supports this natively with job matrices and needs clauses. Each check is a separate job, they all depend on the "build" job that creates the Docker image or deploys to preview, and they run concurrently. The PR status page shows five separate check indicators, each independently green or red.

For teams on tighter CI budgets, you can split checks into "fast" (unit tests, header scan, dependency audit — no browser needed) and "slow" (accessibility, performance, smoke tests — need preview deployment). Fast checks run immediately on push. Slow checks run only when the PR is marked ready for review. This halves the CI cost for draft PRs while keeping full coverage before merge.

Threshold tuning: block vs. warn vs. track

Not every finding should block the merge. The teams that sustain CI-integrated QA long-term use three tiers:

Block: new critical or high-severity findings. New accessibility violations at the serious/critical level. Performance regression beyond threshold (LCP >2.5s, CLS >0.1). Missing CSRF tokens on POST forms. Any new high-severity CVE in dependencies.

Warn: medium-severity findings posted as a PR comment. The author sees them, acknowledges, and can merge. Examples: heading hierarchy gaps, performance metric within 10% of threshold, moderate dependency vulnerability with no exploit in the wild.

Track: informational findings logged to a dashboard but not surfaced on the PR. Total page weight trends, low-severity accessibility notes, technology version inventory. These feed your quarterly QA review without slowing daily development.

Start with everything on "warn" and promote to "block" only after two weeks of running — this lets you calibrate thresholds against your actual codebase without blocking every PR on day one.

The maintenance contract

CI-integrated QA has an ongoing cost: baseline maintenance. When axe-core adds a new rule, or Lighthouse updates its scoring algorithm, or a new CVE database entry triggers a false positive, someone needs to update the baseline or suppressions. Budget 30 minutes per sprint for QA pipeline hygiene. Most of that time is reviewing new findings that appeared without code changes (upstream rule updates) and deciding whether to suppress or fix.

The alternative — not maintaining baselines — leads to pipeline rot. Developers start ignoring warnings, then disabling checks, then removing them. One person on the team owning "QA pipeline health" as a recurring task prevents this. That person doesn't fix every finding; they ensure every finding reaches the right person.

Getting started this week

If you're starting from zero, here's the sequence: Week 1, add Lighthouse CI with a performance budget on your three most important pages. Week 2, add axe-core accessibility scanning on the same pages. Week 3, add security header checks (no browser needed, fastest to set up but least impactful alone). Week 4, add Playwright smoke tests on your critical user flows.

By the end of the month, every PR gets four automated quality checks running in parallel. The fifth — unit and integration tests — you presumably already have. If not, start there.

If you'd rather skip the DIY wiring and get all five checks from a single scan, kuality.io runs accessibility, performance, security headers, SEO, form validation, broken links, and cookie compliance in one pass — with CI integration coming in our next release.