Question 1

What does a test plan contain?

Accepted Answer

List the sections, but don't give a dry list — add a few words on why each exists: scope (what is and isn't tested — this cuts off later disputes), approach (levels, types, techniques), environments and test data, entry/exit criteria (objective start and finish conditions), risks and dependencies, roles and schedule, reporting format. Close with a practical note: "On my team this fits on one A4 — we keep it as a living page in Confluence and update it when scope changes. A 20-page document would go unread by the second sprint." That shows you know both the theory and the reality.

Question 2

What are entry and exit criteria and why are they needed?

Accepted Answer

Entry criteria are the conditions to start testing: build deployed, smoke passed, acceptance criteria approved, test data and environment ready. The benefit: you don't burn time on a half-finished build, and you have an objective answer to "why haven't you started?". Exit criteria are the conditions for calling testing done: 0 open Critical/High, ≥95% of planned cases executed, regression passed on critical flows, remaining defects accepted in writing. The benefit: "when are we done?" rests on numbers, not feelings. Save the key sentence for last: "These criteria protect QA from pressure — the release decision rests on agreed, objective conditions."

Question 3

What would you do if your team has no test plan?

Accepted Answer

I don't start by proposing a big document — nobody would write it. I start small: write a one-page plan, try it on one release and demonstrate the value with a real outcome (e.g. "because we wrote the scope up front, the admin module being untested wasn't a surprise on release day"). Then I turn the repeating parts into a template and add a release checklist. In parallel I write down the team's unspoken agreements — which browsers we support, whether we ever release with an open critical — which effectively becomes the start of a test strategy. The emphasis: producing a document isn't the goal, making expectations transparent is.

Question 4

Scope changed mid-release. What do you do with the test plan?

Accepted Answer

I treat the plan as a living document and update it immediately — carrying on with the old plan is the biggest mistake. The steps: (1) estimate the testing volume of the new scope — how many extra cases, how much wider the regression; (2) compute the gap against the current schedule: either the deadline moves, or something leaves scope, or risk is accepted — I present all three options with numbers; (3) we take the decision together with the PO and I version the plan (what changed, who approved); (4) I add the new risks to the risk section. The key nuance: I don't say "there isn't enough time" — I present options. That positions QA as the side offering solutions, not the side bringing problems.

Test plan section	What goes in it	Why it matters
Scope (in / out)	What is tested and — especially — what is NOT tested	The most important section: it aligns expectations up front and prevents later disputes
Test approach	Which levels, types and techniques will be applied	The team shares one approach and gaps become visible
Entry criteria	What must be ready before testing starts (build deployed, smoke passed, test data available)	Prevents wasting time on half-finished builds
Exit criteria	Conditions for calling testing done (0 critical bugs, 95% of planned cases executed)	Gives an objective answer to "when are we done?"
Environment and test data	Which environments, which integrations are mocked, where data comes from	In insurance a real payment gateway can't be hammered — this must be agreed in advance
Risks and dependencies	What could block testing and the contingency	A delay is not a surprise — it was flagged in advance
Roles and schedule	Who is responsible for what, on which dates	Responsibility gaps become visible

Test plan & test strategy