Software Engineering

Question 1

(a) Green means all independent stages pass: $P = 0.99 \times 0.98 \times 0.95 \times 0.90 = 0.829521.$ Probability of at least one flaky false failure $= 1 - P = 0.170479 \approx 0.1705$. Why: independence ⇒ multiply pass probabilities; complement gives failure. (2 for product, 2 for complement)

(b) The commit is eventually green if at least one of $N$ independent runs is green. Probability all $N$ fail $=(1-P)^N$, so $P_{\text{eventual}}(N) = 1-(1-P)^N.$ For $N=3$, $P=0.829521$: $(1-P)=0.170479$, $(0.170479)^3=0.004954$, so $P_{\text{eventual}} = 1 - 0.004954 = 0.995046 \approx 0.9950.$ (2 derivation, 3 numeric)

(c) Let $q=1-P$. Runs stop at first green; number of runs $R\in\{1,\dots,N\}$.

• $R=k$ (for $k<N$): first $k-1$ fail, $k$-th green: prob $q^{k-1}P$.
• $R=N$: either succeeds on $N$-th (prev fail) or all fail — either way $N$ runs used: prob $q^{N-1}$.

$E[R] = \sum_{k=1}^{N-1} k\,q^{k-1}P + N q^{N-1} = \frac{1-q^N}{1-q}$ (the standard truncated-geometric mean, since $1-q=P$). For $N=3$, $q=0.170479$: $E[R]=\frac{1-0.004954}{0.829521}=\frac{0.995046}{0.829521}=1.19956\approx 1.20 \text{ runs}.$ Cost per run =6\times\0.02=$0.12$. Expected cost$=1.19956\times0.12=$0.14395\approx$0.144$. (3 derivation, 2 numeric)

(d) With $p_4=1.0$: $P'=0.99\times0.98\times0.95=0.92169$, $q'=0.07831$.

• $P_{\text{eventual}}(3)=1-0.07831^3=1-0.00048=0.99952$.
• $E[R]'=\frac{1-0.07831^3}{0.92169}=\frac{0.99952}{0.92169}=1.08444$ runs → cost =\0.13013$.

Comparison: raising flakiness fix drops expected cost from $0.144 → $0.130 (~10%) and raises eventual-green from 0.9950 → 0.99952 (fewer masked real failures). Raising $N$ improves eventual-green but increases cost and, critically, retries mask genuine failures — a false economy. Flakiness is a form of technical debt (accidental/testing debt): retries pay recurring "interest" (compute + hidden bugs) whereas fixing stage 4 pays down principal. Preferred lever: reduce flakiness. (2 recompute, 2 quantitative comparison, 2 tech-debt argument)

Question 2

(a) Transition table:

Terminal states: CANCELLED, DELIVERED, REFUNDED. DAG proof: assign a topological rank r(CREATED)=0, PAID=1, SHIPPED=2, DELIVERED=3, CANCELLED=1, REFUNDED=2. Every listed transition goes strictly from lower to higher rank, so no edge closes a cycle back to an earlier state ⇒ no cycle ⇒ DAG. Idempotency implication: because state only advances forward, a PATCH that says "advance to PAID" applied to an already-PAID order can be made idempotent (return current state / 409 rather than re-advancing), since no path returns to an earlier state. (2 table, 2 proof, 1 idempotency)

(b)

PUT vs PATCH: PUT means replace the full resource and should be idempotent on the whole representation; using it for a state advance implies the client sends the entire order and can overwrite fields. PATCH expresses a partial modification (just the state), matching the intent of "advance state", and lets the server enforce transition rules and reject illegal jumps with 409. (1 per correct endpoint row ≈5, 2 PUT/PATCH)

(c) offset $=(page-1)\times limit = (3-1)\times20 = 40$. Item indices returned: 40–59 (0-based). Offset failure: between fetching page 2 and page 3, if a new item is inserted at the front, every existing item shifts by one index; the item previously at index 40 moves to 41, so page 3 re-shows an item already seen on page 2 (or skips one on deletion). Cursor/keyset pagination uses a stable sort key (e.g. WHERE id > last_seen_id ORDER BY id LIMIT 20); inserts/deletes elsewhere don't shift the cursor, so no duplicates/skips. (2 offset+range, 3 concurrency explanation)

(d)

Given an order in state SHIPPED When the client requests to cancel it Then the request is rejected with 409 Conflict and the order remains SHIPPED.

Classification: integration test — it exercises the API endpoint together with the state-machine enforcement and (likely) persistence layer, not a single isolated function. (2 GWT+status, 1 classification)

Question 3

(a) Two decision points (x>0 and y>0, then x>0 or y>0). Counting each boolean as we assess branch coverage of the two ifs: decisions = 2, so cyclomatic complexity $V(G) = \text{decisions} + 1 = 2 + 1 = 3.$ (Equivalently 3 linearly independent paths / 3 return outcomes.) Minimum test cases for branch coverage = 3 (each if needs a true and false outcome; three tests suffice since they chain):

This exercises both outcomes of both if decisions. (2 complexity, 2 min count, 2 test set)

(b) Branch coverage requires each decision to take true & false; path coverage requires every full route through the CFG. The compound conditions and two sequential ifs give more distinct condition-combinations. Reachable end-to-end paths (by output): "A", "B", "C" = 3 primary paths, but "B" is reachable two sub-ways: (x>0, y≤0) and (x≤0, y>0). So there are effectively 4 distinct input-condition paths, while our 3-test branch suite only exercised the (x>0,y≤0) variant of "B" — it never runs (x≤0, y>0). Path coverage would demand that fourth case too. (2 count, 2 uncovered path)

(c) Mutation testing seeds small faults (mutants) into the code and checks whether the test suite fails (kills) on them. Mutation score: $\text{score} = \frac{\text{killed mutants}}{\text{total non-equivalent mutants}}.$ Mutant: x > 0 and y > 0 → x > 0 or y > 0.

• Kills it: input $(x=1, y=-1)$. Original: first if false → "B". Mutant: first if true → "A". Outputs differ (B vs A) ⇒ a test asserting "B" fails ⇒ mutant killed.
• Does not kill: input $(x=1, y=1)$: original "A", mutant also "A" (both true) ⇒ no difference ⇒ survives. With 5 mutants, only this one surviving means 4 killed: $\text{score} = \frac{4}{5} = 0.8 = 80\%.$ (2 definition, 2 kill/no-kill inputs, 2 score)

(d) Red-Green-Refactor:

• Red: write first failing test, e.g. assert classify(1, 1) == "A" — fails because classify doesn't exist / returns nothing.
• Green: minimal code to pass, e.g. def classify(x,y): return "A" (hard-coded), then add tests for "B" and "C" driving the real conditionals until all green.
• Refactor: once green, extract the sign logic — e.g. both = x>0 and y>0; either = x>0 or y>0 or a lookup on (x>0, y>0) — improving readability without changing behaviour, re-running tests. Code smell addressed: duplicated/nested conditional logic (repeated x>0, y>0 comparisons) — often labelled duplicated condition / complex conditional. (1 red, 1 green, 1 refactor, 1 smell)

[
  {"claim":"Q1a green probability = 0.829521 and false-failure prob = 0.170479",
   "code":"P=Rational(99,100)*Rational(98,100)*Rational(95,100)*Rational(90,100); result = (abs(float(P)-0.829521)<1e-6) and (abs(float(1-P)-0.170479)<1e-6)"},
  {"claim":"Q1b eventual green within N=3 approx 0.995046",
   "code":"P=0.829521; q=1-P; result = abs((1-q**3)-0.995046)<1e-5"},
  {"claim":"Q1c expected runs for N=3 approx 1.19956 and cost approx 0.14395",
   "code":"P=0.829521; q=1-P; ER=(1-q**3)/(1-q); result = abs(ER-1.19956)<1e-4 and abs(ER*0.12-0.14395)<1e-4"},
  {"claim":"Q1d with p4=1, E[R]=1.08444 cost 0.13013",
   "code":"Pp=0.99*0.98*0.95; q=1-Pp; ER=(1-q**3)/(1-q); result = abs(ER-1.08444)<1e-4 and abs(ER*0.12-0.13013)<1e-4"},
  {"claim":"Q2c page 3 limit 20 offset = 40",
   "code":"page=3; limit=20; offset=(page-1)*limit; result = offset==40"},
  {"claim":"Q3c mutation score with 1 survivor of 5 = 0.8",
   "code":"result = Rational(4,5)==Rational(4,5) and abs(4/5-0.8)<1e-9"}
]