QA and Testing Strategy for Custom Software Projects

Testing Is Not a Phase, It's a Strategy

Teams that treat QA as the week before launch where everything gets checked are already behind. By the time you're manually clicking through a full application looking for bugs a week before a deadline, you've lost the ability to fix anything structural — you can only patch symptoms. A real software QA testing strategy is designed at the start of a project, alongside the architecture, and runs continuously: automated tests written as features are built, not bolted on afterward.

The projects where this bites hardest are the ones under the most schedule pressure, which is exactly backwards from how teams actually behave — the more rushed a project gets, the more testing gets treated as optional. We've made continuous testing a non-negotiable part of how we scope sprints specifically because deadline pressure is when the temptation to skip it is highest, and that's when a regression slipping through causes the most damage to a client relationship.

The Test Pyramid We Actually Use

We build on the standard test pyramid — a large base of fast unit tests covering individual functions and components, a smaller layer of integration tests checking that services and modules work together correctly, and a thin top layer of end-to-end tests that simulate a real user flow through the browser or app. The shape matters: a suite that's mostly end-to-end tests is slow to run and constantly flaky, while a suite that's mostly unit tests runs in seconds and catches most regressions immediately.

In practice this means a typical feature ships with a dozen or more fast unit tests, a handful of integration tests covering how it interacts with the database or external services, and one or two end-to-end tests covering the critical path a real user would take. That ratio isn't arbitrary — it reflects how expensive each type of test is to write, run, and maintain relative to the confidence it actually provides.

Automated Testing in the CI Pipeline

Every pull request runs the full automated test suite before it can be merged, which means broken code physically cannot reach production without someone actively overriding a failing check. This is the mechanism, not just the intention, that keeps quality from degrading over a project's lifetime. We've inherited codebases with an impressive-looking test folder that nobody actually ran in CI — tests that exist but don't run in the pipeline provide false confidence, which is arguably worse than no tests at all.

What Still Needs a Human

Automated tests are excellent at catching regressions and verifying logic, and useless at catching a confusing flow or a layout that breaks on a small phone screen. Manual QA and exploratory testing still matter, particularly around new features and UI-heavy work, and particularly right before a release. We assign real testing time to this rather than treating it as something engineers do informally between other tasks.

We schedule dedicated exploratory testing time before any release that touches a core user flow, treated as its own task on the sprint board rather than something squeezed in if time allows. The tester's job in that window isn't to confirm the feature works as specified — the automated suite already does that — it's to try to break it in ways the spec never anticipated.

Testing Strategy Scales With Risk, Not With Project Size

A marketing site doesn't need the same test rigor as a payments flow, and treating them identically wastes effort in one direction or under-protects in the other. We calibrate test investment to the cost of failure: anything touching money, user data, or authentication gets heavier coverage and more manual review; low-risk, easily-reversible features get lighter coverage so the team isn't spending disproportionate time testing things that don't matter much if they break.

We also track a simple metric over the life of a project: how often a bug reaches production versus how often it gets caught by the test suite or a reviewer first. When that ratio starts drifting toward more bugs reaching production, it's usually a sign the testing strategy hasn't kept pace with how the codebase has grown, and it's a prompt to revisit coverage rather than just working harder to catch things manually.

This risk-based calibration also determines how much test automation we invest in maintaining over time. A flaky end-to-end test covering a low-traffic admin page isn't worth the engineering hours to keep stable; a flaky test covering the checkout flow is worth fixing immediately, even if it means pausing other work. Treating all test failures as equally urgent is its own kind of miscalibration.

The bugs that make it to production are rarely the ones nobody thought to test — they're the ones somebody decided weren't worth testing.

Making QA Someone's Actual Job

On any project of meaningful size, testing strategy needs an owner — someone whose job includes asking how we know this works for every feature, not just the engineer who happened to build it. That doesn't mean a dedicated QA hire on every project, but it does mean testing responsibility is explicit rather than assumed to be everyone's job, which in practice means no one's.

For the full picture of how we run engagements, see our delivery process.