Three Weeks to Release With a 31% Refund Module
A payments team has three weeks of test time before a mandatory release. Its suite contains 1,400 automated tests with 62% line coverage overall, but the new refund module sits at 31%. Static analysis reports 40 medium findings, all located in the legacy parser that handles inbound payment files. An external penetration test found two medium issues: a verbose error page that leaks stack traces, and a missing rate limit on the password reset endpoint. Load testing shows p95 latency of 1.8 seconds against a 2-second target. The release train runs every six weeks and delaying costs an estimated $250,000 in missed contract milestones. The team lead proposes running the existing automated suite, fixing nothing, and recording the penetration test findings as accepted risks.
1. Evaluate the proposal to record both penetration test findings as accepted risks.
Read the worked answer
The two findings are not equivalent and should not be bundled into one acceptance decision.
The missing rate limit on password reset is a cheap fix with a direct abuse path: an unauthenticated attacker can enumerate accounts and trigger reset mail at scale, which is both a confidentiality risk and an availability cost. Cost to fix is small and the change surface is narrow, so accepting it is hard to defend in front of a customer security questionnaire. Fix it inside the three weeks.
The verbose error page leaks stack traces, framework versions and file paths. Medium severity is fair, but it is a reconnaissance amplifier when combined with the parser findings. A configuration change to return a generic error with a correlation ID is low risk and should also be done.
More importantly, risk acceptance is not a team lead's decision. It requires a named business owner who understands the exposure, a documented rationale, compensating controls, a review date, and a record in the risk register. "We ran out of time" is a schedule statement, not a risk justification. If the business truly accepts residual risk, get the signature and set an expiry date so it does not silently become permanent.
2. Use the coverage data and findings to allocate the three weeks.
Read the worked answer
Line coverage is an aggregate proxy and is hiding the actual risk distribution. 62% overall with a new money-handling module at 31% means the aggregate is flattered by mature, low-change code that was already well tested.
Priority order, with reasoning:
- Refund module. It is new, it moves money, and it is the least covered. Target branch coverage on changed code rather than the whole module; focus on boundary conditions, idempotency of repeated refunds, partial refunds, currency rounding, and refund after a chargeback. This is where an undetected defect becomes a financial and reconciliation incident.
- Parser findings. The parser takes untrusted input from external payment files. Triage the 40 findings by exploitability given that exposure, not by count. Malformed length fields, path traversal on referenced files and unsafe deserialization should be examined first; a hardcoded informational string is noise. Run the parser against fuzzed and malformed files if time allows.
- Authentication and session boundaries. Add tests for reset token reuse, token expiry, and whether the reset endpoint behaves differently for valid versus invalid accounts.
Keep the full automated suite running on every change as a regression gate. Latency at 1.8s against a 2s target is thin but not a blocker unless the penetration test or fuzzing changes the load profile; note the headroom in the release record.
3. What release decision do you recommend, and what conditions attach to it?
Read the worked answer
Recommend a conditional go, not an unconditional one and not a blanket delay.
The $250,000 milestone cost sets the bar that a delay must clear: delay is justified only if the residual risk is plausibly larger than that. On current evidence the dominant risks are concentrated in two places, and both can be reduced inside the window.
Conditions for release:
- Rate limit and generic error page fixed and verified before the cut.
- Refund module branch coverage on changed code raised to an agreed threshold, with the specific scenarios above executed and their results attached to the release record.
- Parser findings triaged with an explicit list of what was deferred, each with an owner and a target date.
- A named business owner signs the residual risk register entry, with an expiry date.
- Rollback plan tested, not just documented, since payments rollbacks carry data-consistency consequences.
- Detection in place for the accepted risks: alerting on reset-request volume anomalies and on parser exceptions.
If the refund coverage target is not met at the cut, that is the specific trigger to delay, not the general schedule pressure. Making the trigger narrow and pre-agreed prevents the argument from being relitigated on the last day.