Short answer: QA on a small web team means treating testing as a separate, deliberate pass (not something that happens automatically while coding), prioritizing real devices, forms, and data edge cases in that order, and using a small number of automated end-to-end tests to protect the paths that are expensive to break.
Most writing about QA testing assumes a dedicated QA team, a test plan document, and a bug tracker with a triage process. On a small project, often just me, sometimes me and one other developer, that's not the reality, and pretending otherwise means either skipping testing entirely or building process theater that doesn't fit the team size. Here's what actually happens instead, as part of the QA testing I do alongside development.
Is QA a role or a job title on a small team?
On a small team, "QA" isn't a job title, it's a hat someone puts on before something ships. The important shift is treating it as a distinct pass, not something that happens automatically while writing code. Building a feature and testing a feature use different mental modes: one is "does this work the way I intended," the other is "what happens if someone does something I didn't intend." Doing both at once, in the same sitting, means the second mode rarely gets its fair share of attention.
What should you test first, in what order?
- The happy path, on real devices. Not just Chrome DevTools' responsive mode, an actual phone, because touch targets, keyboard behavior, and viewport quirks genuinely differ from a resized desktop browser window.
- Forms, specifically. Forms are where most real bugs live: submitting with empty required fields, submitting with intentionally malformed input (an email without an
@, a phone number with letters in it), double-clicking submit, going back after submitting. A contact form that silently fails on the third of these is worse than no contact form, because the site owner thinks it's working. - The edge of the data, not just the middle. A project list that looks fine with six items might break with zero items (does the empty state actually exist, or does it render a broken layout?) or with sixty (does pagination or a scroll container kick in, or does the page just get absurdly long?).
- Every interactive element, deliberately, not just the ones in the main flow. The mobile menu close button. The modal's Escape-key handler. The scroll-to-top button at the exact scroll position it should appear. These are exactly the things that get skipped in a rushed manual pass because they're not part of the "main" flow, and exactly the things a real user finds within the first five minutes.
Which testing tools are actually worth using on a small team?
Automated testing on a small project isn't about coverage percentage, it's about protecting the few things that are expensive to get wrong and easy to accidentally break. A handful of end-to-end tests covering the actual critical paths (can a user submit the contact form, does the checkout flow complete) catch regressions that a manual pass might miss after a refactor, without the overhead of maintaining a large test suite that a two-person team doesn't have time to keep green.
Beyond that: a linter catches a category of bug before it's even run. TypeScript, where the project uses it, catches another category. Browser console errors, actually reading them, not just glancing, catch a surprising number of silent failures that never show up visually but would matter to a crawler or an accessibility tool.
What are the honest limits of small-team QA?
A two-person team's QA process will never match a dedicated QA team's coverage, and pretending otherwise sets the wrong expectation with a client. What it can do is cover the actual likely failure modes, the ones a manual pass through real devices, real forms, and real edge cases will catch, instead of leaving testing as a vague afterthought that happens only if there's time left at the end. There usually isn't time left at the end, which is exactly why it has to be a deliberate step, not a hopeful one.