A Testing Strategy That Fits a Lean Team

When testing time is limited, coverage percentage is the wrong target. The right target is: are the paths a user would take to complete core tasks covered? A failing test on an edge case that affects 0.1% of users is less valuable than a test that would catch the checkout flow breaking.

Map your critical paths first. Then write tests for those. Coverage of the rest is a bonus.

Unit tests are fast and easy to write. They are also easy to game: a test that passes because it mocks everything is testing nothing. Integration tests that hit real services or a real database catch a whole category of failures that unit tests miss.

For a small team, a suite of integration tests over the core flows, run on every PR, provides more signal than a large unit test suite that mocks heavily.

AI now writes first drafts of tests, keeps selectors up to date, and triages failures. Playwright has become the default end-to-end framework, and AI test generation on top of it is mainstream.

People still own the strategy: deciding what matters, reasoning about edge cases, and checking that generated tests actually cover business risk.

• Critical-path end-to-end tests pass in CI.
• Database migrations have been run against a copy of production data.
• Error tracking is on, and someone is watching it after release.
• There is a tested way to roll back.
• Release notes list anything customers will notice.