Test Planning & Governance
How a team decides what to verify, how deeply, when to start and when a build is good enough to ship. Interviewers probe it because owning a release takes more than writing tests.
on this pageshowhide
explore
- Risk-Based Selection4 questions
- Strategy & Plan Documents4 questions
- Entry & Exit Criteria4 questions
- Lifecycle Models4 questions
- Shift-Left Practices4 questions
- Regression & Smoke Suites4 questions
- Test Effort Estimation4 questions
- Progress Tracking4 questions
- Requirements Traceability23 questions
- Matrix as Artefact4 questions
- Tracing Both Directions4 questions
- Gaps & Orphans4 questions
- Two Denominators3 questions
- Change-Impact Analysis4 questions
- Lightweight vs Regulated4 questions
- AI & Data Scientistrole
- AI Engineerrole
- Backend Developerrole
- Data Engineerrole
- Frontend Developerrole
- Full Stack Developerrole
- Game Developerrole
- Java Backend Developerrole
- Java SDETrole
- Kotlin Backend Developerrole
- MLOps Engineerrole
- Machine Learning Engineerrole
- QA Engineerrole
- Software Architectrole
- iOS Developerrole
questions
page 2 of 2How do you buffer a test estimate for fix-and-re-test cycles and days lost to blocked builds?
basics
~20 sModel the drivers rather than adding a flat percentage: expected defect arrival times re-test cost per defect, divided by the measured fraction of days the build and environment are usable. Keep the buffer named, visible and tied to stated assumptions.
What does a missing requirement-to-case traceability link cost on each side, and why are the two noticed at different moments?
basics
~20 sOn the requirement side it looks unverified though it was tested, so the work is repeated. On the case side nobody can justify the case, so it is never pruned. Only the first has a forcing moment.
Why does a traceability-derived impact set both overstate and understate what a change actually affects?
basics
~20 sIt overstates because shared components pull in every requirement that reaches them, changed behaviour or not. It understates because real coupling — shared data, ordering, implicit contracts — was never written down as a link at all.
Traceability links in an area have gone unmaintained for two releases. What can an impact analysis built from them still be used for?
basics
~10 sUse it as a floor, never a ceiling. What stale links include still names relationships that were genuinely real; what they omit proves nothing, because the record stopped following the product two releases ago.
Why is an acceptance criterion whose only linked test case is permanently skipped worse than one with no linked case at all?
basics
~20 sThe link still exists, so the record reads the criterion as verified while nothing runs against it. An unlinked criterion is visible and gets an owner; a permanently skipped case hides the same hole behind a joined-up chain.
Work shipped under light traceability now needs an evidence trail — what can you honestly rebuild after the fact?
basics
~20 sAnything still stored can be recovered: which change addressed which requirement, which suite ran against which build, and what it produced. What cannot be rebuilt is what nobody recorded — intent, judgement, and contemporaneity itself.
Should a traceability record be generated from links in the work, or maintained as its own document?
basics
~20 sGenerate it wherever the links already live on the work itself: a generated view can only show what the work records, and costs nothing to reproduce. An authored document shows more, but is only as true as its last edit.
Who creates a traceability link from a requirement to a test case, and at what moment?
basics
~20 sThe person producing the thing being linked creates it, at the moment they create it: the case author when writing the case, the engineer when opening the change, whoever files a defect when filing it. No separate scribe pass afterwards.
A release with near-total code-execution coverage fails acceptance because an agreed behaviour was never built — why did that figure not warn anyone?
basics
~20 sBecause that figure divides by the code that exists. Behaviour nobody implemented contributes no code, so it cannot appear as unexecuted code — cutting work can even raise it. Only the requirement-side denominator holds the missing behaviour.
Release exit criteria are unmet on ship day. How do you assemble the recommendation you hand to the decision-maker?
basics
~10 sHand over evidence and options, not a verdict: what was covered, which criteria are unmet and by how much, what is unverified, and realistic choices. The accountable owner signs.
How do you decide what moving from stage-gated verification to continuous verification actually changes?
basics
~20 sSort the existing checks by what makes them safe to run constantly: speed, determinism, self-diagnosis and freedom from scarce resources. Those become standing assertions evaluated on every change and against the running system; the rest still needs a release boundary, and saying which is which is the decision.
How do you report a test cycle so it conveys confidence rather than a pass-rate percentage?
basics
~20 sReplace the ratio with statements a reader can act on: what was exercised and what was not, what the cycle learned about each area, where the remaining uncertainty sits, and how much of that is measurement rather than product. Keep the percentage as detail, never as the headline.
How do you decide the tier structure for a regression pack, and what confidence does each tier actually buy?
basics
~20 sWork backwards from the feedback time each decision can tolerate, then place every signal in the earliest tier that can produce it reliably inside that tier's budget. Every tier needs an owner, a blocking action and a written claim about what green means.
As the owner of a risk register, how do you defend a deliberate decision to leave an area unverified?
basics
~20 sMake it a decision, not an omission: name the failure being accepted, score it on the same scale as what you did verify, offer a cheaper containment, and have the consequence-owner accept it with a review date.
How far left should verification move, and which checks genuinely cannot be shifted earlier?
basics
~20 sShift a check left when its findings survive the move and the artefact it inspects is stable enough to be worth inspecting. Emergent behaviour — real load, real data volumes, real third-party systems, real users — produces signals that only exist later, and no amount of early review substitutes for them.
When only part of a product carries an external evidence obligation, do you apply one traceability standard everywhere or two?
basics
~20 sDecide from where the obligated behaviour actually reaches, not from the module diagram. One standard everywhere is simple but taxes work that never needed it and decays into form-filling; two are cheaper until the boundary erodes unnoticed.
What does test point analysis size a test effort from, and why is it rarely used?
basics
~20 sTest point analysis is a formula-based method that sizes testing from a counted functional size of the system, adjusted for quality characteristics, risk and environment factors. It is rare because almost nobody maintains a functional size count to feed it.
Should a traceability link attach to a whole requirement, one acceptance criterion, or one scenario?
basics
~20 sAttach it at the acceptance-criterion grain in most products. A whole-requirement link is quick to write and too coarse to answer anything useful a year later; a per-scenario link answers precisely but multiplies rows faster than any team keeps them current.
What are suspension and resumption criteria for a test cycle, and when do you invoke them?
basics
~20 sSuspension criteria are pre-agreed conditions for stopping a test cycle in flight — a build too broken to yield information. Resumption criteria state what must be true to restart, including which earlier results the interruption invalidated.
How do you use the agile testing quadrants to decide which checks a release needs?
basics
~20 sThe quadrants classify checks on two axes: business-facing versus technology-facing, and supporting the team versus critiquing the product. Plot the planned checks on the grid, and an empty cell shows a kind of evidence the release does not have.
Two teams will build both sides of an interface in parallel. How do you verify it before either side exists?
basics
~20 sAgree a written, machine-checkable description of the interface first — request and response shapes, field meanings, error cases — then have each side check itself against that same description in its own build: the provider that it can produce those responses, the consumer that it works against a stand-in generated from them.
A requirement is split in two after test cases already link to it — how do you keep both traceability reads intact?
basics
~20 sRe-point each affected link deliberately: decide per case which of the two new requirements it now verifies, sometimes both, sometimes neither cleanly. Keep the retired identifier resolvable so older results and defect records still lead somewhere.
When you hand on a change-impact set, what does the confidence you attach to it come from?
basics
~20 sConfidence comes from observable properties of the walk: how recently the links in that area were maintained, how much of the set came from links rather than your own reading, and whether earlier sets caught what actually broke.
When traceability links are maintained by hand, what does a gap and orphan analysis over them actually measure?
basics
~20 sIt measures the link set, not the system. With links entered by hand the findings track how well people keep those links current, so a clean result means nobody has recorded a gap, not that everything is verified.
What is a test policy, and when is one worth writing above a test strategy?
basics
~20 sA test policy is a short organisation-level statement of quality objectives and non-negotiables every team must meet - the frame a strategy obeys. It earns its cost only with several teams to align, or an external obligation.
showing 31–55 of 55