Test Estimation

Three things to put on the table:
1. The work breakdown structure (WBS) — the itemised list of tasks (test design, environment setup, execution, defect logging, retest, reporting) with hours against each. This is the evidence that the 14 hours is built from real work, not a feeling.
2. The assumptions — e.g. "this assumes the test environment is available and stable from day one, and that the build is delivered defect-light." If the PM wants a day, ask which assumption they want to change.
3. A range, not a point — "12 to 16 hours depending on defect volume." This signals honestly where the uncertainty is.

Why a range beats a single "8 hours": a single point implies a precision you do not have and sets you up to be "wrong" the moment reality differs by an hour. A range communicates the uncertainty truthfully, invites a conversation about what drives the high end (usually defect volume and environment stability), and protects you because you committed to a band, not a false certainty.

Correct PERT formula: E = (O + 4M + P) ÷ 6

Correct calculation: (2 + 4×6 + 10) ÷ 6 = (2 + 24 + 10) ÷ 6 = 36 ÷ 6 = 6 hours

In this particular case the answer happens to be the same (6 hours) because the values are symmetric, but the working is wrong and would give a different answer for almost any other input.

What the mistake changes: a plain average (O + M + P) ÷ 3 treats best case, likely case and worst case as equally probable. PERT does not — it weights the Most Likely value four times as heavily, which is the whole point of the technique. With skewed inputs (say O=2, M=3, P=20) the plain average gives 8.3 h but PERT gives (2 + 12 + 20) ÷ 6 = 5.7 h. Using the wrong formula on skewed tasks systematically over- or under-estimates and discards PERT's main benefit: anchoring on the realistic case while still accounting for the tail risk.

A defensible WBS for the dog-registration renewal form:
- Review requirements and acceptance criteria, write test cases — 4 h
- Set up test environment and seed test data (owners, multiple dogs, payment accounts) — 2 h
- Execute happy-path tests (single dog renewal, payment success) — 2 h
- Execute negative / boundary tests (invalid card, multiple dogs, missing fields) — 3 h
- Exploratory session on the payment and multi-dog logic — 2 h
- Log and manage defects + retest after fixes — 3 h
- Regression check on the existing registration flow — 2 h
- Test report and sign-off — 1 h
Total estimate: ~19 hours (a sensible band would be 17–22 h)

Two assumptions the estimate depends on:
1. The test environment and payment sandbox are available and stable from day one.
2. The build is delivered defect-light — heavy defect volume on first execution would push the retest and defect-management line well past 3 hours, which is why the upper end of the range exists.

A senior would note the multi-dog-per-household rule is the riskiest area (combinations of dogs, part-payments, removals) and would weight exploratory and negative testing there, and would give the total as a range with the defect-volume assumption called out explicitly.