How I approach test plans
When I create a test plan, it's the main document that defines how I'll approach testing for a sprint. I write one per sprint, before development starts, so stakeholders, business analysts, and developers know upfront what I'll test and how.
I always include my initial test cases in the plan, at minimum the critical ones. Requirements change during development, so I keep my test plans concise and flexible enough to adjust without rewriting them from scratch.
A test plan can be as simple as a checklist, or as formal as the client needs. I try to match the formality of my test plan to how formal the sprint (or the client) actually is. But one thing I've noticed holds true: the more concise or direct the test plan is, the more feedback I actually get on it.
Test plans are also most effective early in the lifecycle. Once I share a test plan, developers can review it and flag gaps I might have missed, or catch something that was never scoped during requirements gathering, which can be a serious gap on its own. This creates an early feedback loop for everyone.
I've had cases where writing test cases surfaced things the business never thought through during planning. Catching that early saves everyone time. The principle is simple: the earlier a bug or gap is caught in the lifecycle, the cheaper it is to fix.
Same sprint, written at both ends of the formality range.
Flight Harbor, a travel booking platform, is adding a Stripe integration so it can accept card payments for flights, seat upgrades, and baggage add-ons. First time money moves through the product.