# ShopBridge Cross-Platform Behavior Parity Review (Synthetic Exercise) ## 1. Decision brief - **Product:** ShopBridge (fictional), build 2.4.0 on Web (Chrome 130 / Windows 11), Android (Pixel 7 / Android 15) and iOS (iPhone 14 / iOS 18). - **Mode:** EVIDENCE REVIEW. I inspected the supplied fixtures and executed nothing. - **Scope:** Product page, cart, checkout form and order confirmation. Focus areas are pricing, required-field validation, repeated submission and interrupted-response recovery. - **Verdict: Confirmed divergence.** On repeated activation of one checkout intent, Android created two persistent orders (ORD-A-201 and ORD-A-202). Web and iOS created one each (E-03, E-04). This violates R-03 on Android. - **Shared defects:** None in the reviewed evidence. Pricing (R-01) and required-address validation (R-02) agree and are correct on all three platforms, in single runs. - **Most important next action:** Reproduce F-01 on Android and run a discriminating client-versus-server test (T-01, T-02). Server-side deduplication is unverified on all platforms. - **Limits:** Each scenario has one run per platform. No interrupted-response, offline, accessibility or viewport tests were run (R-04's recovery half is entirely unevidenced). No payment records exist, so duplicate *charges* are neither shown nor implied. Web and iOS passing the 80 ms double-activation run does not show their retry handling is robust. This is not a certification. **Decision rationale:** The Android and Web/iOS runs used the same build, backend, catalog, flags and starting state, with the same 80 ms interval. Only Android shows two requests and two orders for one intent. The order count comes from the persistent snapshot (E-04), not just the client log. ## 2. Baseline and evidence ### Requirements (all Supplied) | ID | Journey | Observable expected outcome | Source | Allowed variation | |---|---|---|---|---| | R-01 | Pricing | DESK-01 at 40.00 × 2, SAVE10 10% off merchandise, shipping 5.00 after discount, tax 0.00, total **77.00** | Supplied | None stated | | R-02 | Checkout form | Empty address line 1 blocks submission and creates no order | Supplied | Native keyboard/picker differences only (R-05) | | R-03 | Submission | One checkout intent creates at most one persistent order, including repeated taps or retries. Every request and retry keeps the same `checkout_intent_id` | Supplied | None | | R-04 | Confirmation / recovery | Confirmation shows the persistent order ID. After an interrupted response the app reconciles the existing intent before retrying and creates no further order | Supplied | None | | R-05 | All | Native keyboards, pickers and button styles may differ if validation, totals, order creation and access to essential actions stay equivalent | Supplied | This is the variation rule | ### Evidence ledger | ID | Source / location | Platform / build | Supported observation | Limitation | |---|---|---|---|---| | E-01 | `pricing-results.csv`, rows PRICE-W/A/I | Web, Android, iOS 2.4.0 | All three: subtotal 80.00, discount 8.00, shipping 5.00, tax 0.00, displayed total 77.00 (matches R-01) | One run each. Displayed values only. Persisted totals appear only in E-04 | | E-02 | `required-address-results.csv`, rows ADDR-W/A/I | Web, Android, iOS 2.4.0 | All three show "Address line 1 is required", with 0 order requests and 0 persistent orders (matches R-02) | One run each. Message text only. Focus handling and screen-reader output are not evidenced. Other fields are untested | | E-03 | `repeated-submit-event-log.txt` | Web, Android, iOS 2.4.0 | Web (12:00:00.080) and iOS (12:02:00.080) ignored the second activation while pending, and each sent one request. Android (12:01:00.080–.090) sent a second request with the same INT-A-01. Responses returned ORD-A-201 (.300) and ORD-A-202 (.380), and confirmation showed ORD-A-202 (.420) | One run each. How activation was delivered is Unknown. Clock sources across platforms are Unknown. The log does not say what happened to the ORD-A-201 response in the UI | | E-04 | `persistent-order-snapshot.csv` | Web, Android, iOS 2.4.0 | Persistent orders per intent: INT-W-01 → 1, INT-I-01 → 1, **INT-A-01 → 2** (ORD-A-201 and ORD-A-202, both 77.00, created) | Snapshot is after all requests. No payment data (none was executed) | ### Comparison controls - **Matched:** Build 2.4.0, staging backend 2.4.0, catalog CAT-17, feature flags, locale, currency, timezone, account QA-104, reset start state, no injected failures, 80 ms interval, and per-platform intent IDs. - **Unknown:** - Input method for the double activation (touch, mouse, or injected). - Whether the runs were sequential or concurrent. Timestamps are 60 s apart, so sequential is likely. - Whether the log clocks are synchronized. - How many repetitions informed each result. - **Unreadable or missing artifacts:** None. All artifacts were pasted. No embedded instructions were found in them. ### Unresolved requirement gaps See F-02 and F-03. ## 3. Parity matrix | # | Scenario | Req / Tests | Web | Android | iOS | Comparison outcome | |---|---|---|---|---|---|---| | S1 | Total for qty 2 + SAVE10 + shipping = 77.00 | R-01 / T-06 | Pass (E-01) | Pass (E-01) | Pass (E-01) | Parity, all correct (single run) | | S2 | Empty address line 1 blocks submit, 0 orders | R-02 / T-07 | Pass (E-02) | Pass (E-02) | Pass (E-02) | Parity, all correct (single run) | | S3 | Two activations 80 ms apart → ≤1 order per intent | R-03 / T-01, T-04 | Pass (E-03, E-04) | **Fail** (E-03, E-04) | Pass (E-03, E-04) | **Divergence** (Android differs) | | S4 | Same `checkout_intent_id` on every request/retry | R-03 / T-05 | Unknown (only one request sent) | Pass (INT-A-01 on both requests, E-03) | Unknown (only one request sent) | Not comparable | | S5 | Confirmation shows a persistent order ID | R-04 / T-01 | Pass (ORD-W-101) | Pass, literal only (ORD-A-202 is persistent; see F-01) | Pass (ORD-I-301) | Agree on the literal rule. Android's confirmation hides ORD-A-201 | | S6 | Interrupted response: reconcile existing intent, then retry, no extra order | R-04 / T-03 | Unknown | Unknown | Unknown | Not assessed | The S3 pass cells for Web and iOS cover only this double-activation case. They do not show that retry handling or server deduplication works on those platforms, because their clients never sent a duplicate request. ## 4. Findings and next actions ### F-01: Android creates two persistent orders for one checkout intent - **Classification:** Confirmed defect. Cross-platform divergence from Web and iOS. - **Affected:** Android 2.4.0, Pixel 7 / Android 15, staging backend 2.4.0. Server-side exposure is possible on all platforms (see hypotheses). - **Linked:** R-03, R-04, R-05. E-03, E-04. Tests T-01, T-02, T-04, T-05. - **Expected vs actual:** - Expected: one order for INT-A-01. - Actual: two requests carrying INT-A-01, two persisted orders (ORD-A-201 and ORD-A-202, both 77.00, `created`), and a confirmation showing only ORD-A-202. - The intent ID was retained (the second half of R-03 holds), but at-most-one-order was violated. - **User impact:** A shopper who double-taps could end up with a duplicate order, and the confirmation does not reveal ORD-A-201. Whether this leads to a duplicate payment is not evidenced, since payment execution was disabled. - **Severity:** High. The core checkout produces a materially wrong persistent result, and whether a practical workaround exists is Unknown (cancellations and refunds are out of scope). **Potential escalation to Critical** if order creation triggers payment capture with no safe recovery. This is a condition, not a finding. - **Confidence:** High that the violation occurred in this fixture, because the client log and the persistent snapshot agree. Low–Medium on frequency and trigger conditions, because there was one run and the timing window is unknown. - **Reproduction (reconstructed from fixture descriptions; the exact UI input method is Unknown):** 1. Reset QA-104 on Android 2.4.0 (Pixel 7, Android 15) against staging 2.4.0. The cart is empty. 2. Add DESK-01, set quantity 2, apply SAVE10, and confirm the total shows 77.00. 3. Enter a valid shipping address. 4. Activate submit twice, 80 ms apart. 5. Observe two order requests with INT-A-01, two order IDs returned, a confirmation showing ORD-A-202, and two persistent rows for INT-A-01. - **Hypotheses (not verified root causes):** - **Client-side:** The Android client lacks or has a late pending-state guard, so the second activation was not suppressed (E-03 shows Web and iOS suppressing it). - **Server-side:** The server did not deduplicate by `checkout_intent_id`. Web and iOS never sent a duplicate, so their server behavior is untested. - **Alternatives:** - The server's deduplication key includes something the second Android request lacked. - The harness injected the activation differently on Android. - A race window exists that other platforms might also hit at different intervals. - **Smallest discriminating tests:** - T-02 replays a same-intent request through a staging-approved tool. Two orders points to the server, and one order with the same ID returned points toward the Android client request. - T-04 sweeps activation intervals to find whether the race window exists on Web and iOS. - **Fix direction and owners (direction only):** - Android engineer: ignore or disable re-activation while a submission is pending, matching Web and iOS. - Backend engineer: enforce one order per `checkout_intent_id` and return the existing order for duplicates. - QA: add the regression tests. - **Acceptance criteria:** - T-01 shows 0 duplicate orders across all runs on all three platforms. - T-02 shows replays of the same intent return a single order. - T-03 shows no new order after an interrupted response. - T-04 shows 0 duplicates across the interval sweep. - T-05 shows the same intent ID on every request. ### F-02: Requirement gap — contract for a duplicate request reaching the server - **Classification:** Requirement gap. Linked R-03, R-04. - **Gap:** The requirements do not say whether a repeated same-intent request should return the existing order ID, an error, or something else, or which ID the confirmation should show. - **Impact:** Without this rule, T-02 and T-03 pass criteria cannot be fully objective. - **Proposed rule (not yet confirmed):** The server returns the existing order for the intent, and the confirmation shows that single ID. - **Owner:** Product owner confirms the rule. ### F-03: Requirement gap — validation and pending-state edges - **Classification:** Requirement gap. Linked R-02, R-05. - **Gap:** R-02 covers only an *empty* address line 1. Whitespace-only input is undefined. R-05 does not specify whether the pending state must be visibly indicated, for example a disabled button. - **Impact:** T-08 is blocked, and parity of pending-state feedback cannot be judged. - **Owner:** Product owner and design. ### Permitted variations None were observed in the supplied evidence. R-05 would permit native keyboard, picker and button-style differences, but none were reported. ## 5. Executable test pack All tests are staging-only, with real payments excluded. Unless stated otherwise, the common preconditions are: a reset copy of QA-104 with an empty cart and no orders, build 2.4.0 on Web/Android/iOS, backend 2.4.0, CAT-17, the same flags, English (US), USD and UTC. Values marked "Proposed fixture" are invented for these tests. Tool names and endpoints are not specified because none were supplied. All tests are Not executed by me. **T-01 (priority 1): Rapid double activation, repeated runs** - **Purpose:** Reproduce and confirm F-01, and check whether Web and iOS stay clean. - **Platforms:** Web, Android, iOS. **Requirement:** R-03, R-04. - **Data:** DESK-01 × 2, SAVE10, a valid address (Proposed fixture: any valid values accepted by staging, recorded exactly). Run 10 times per platform, each with a fresh reset and a fresh intent (Proposed fixture count). - **Actions:** 1. Build the 77.00 cart. 2. Enter the valid address. 3. Activate submit twice 80 ms apart, using timing-controlled input (tooling Unknown). Record the actual interval. 4. Wait for the confirmation. 5. Query the persistent orders for the intent. - **Expected:** 1 request (or ≥2 requests with 1 order), 1 persistent order per intent, and a confirmation showing that order's ID. - **Evidence:** Client event log with timestamps, request records showing `checkout_intent_id`, the persistent-order query result, and a screen recording. - **Pass/fail:** Fail on any run with more than 1 order per intent. Pass only if all runs have exactly 1. - **Notes:** Functional. Automatable if timing is controllable. **T-02 (priority 2): Server idempotency for forced duplicate requests** - **Purpose:** Separate client and server causes (F-01). - **Platforms:** Backend via a staging-approved replay tool, with Web, Android and iOS as sources of captured requests. **Requirement:** R-03. - **Data:** A captured order request from each platform. Replay it 2 times with the same intent ID (Proposed fixture). - **Actions:** 1. Submit normally once per platform. 2. Replay the captured request twice. 3. Query persistent orders for each intent. - **Expected:** Still exactly 1 order per intent. The replay response behavior follows the F-02 rule. - **Evidence:** Replay request/response records and the persistent-order query. - **Pass/fail:** Fail if any intent has more than 1 order. - **Status:** Pass criteria for the response contents are Blocked pending the F-02 rule. The order-count criterion is executable now. **T-03 (priority 3): Interrupted response, reconcile, then retry** - **Purpose:** Cover the unevidenced recovery half of R-04. - **Platforms:** Web, Android, iOS. **Requirement:** R-04, R-03. - **Data:** The 77.00 cart. Staging fault injection that drops the order response after the server processes the request (injection tool Unknown). - **Actions:** 1. Submit. 2. Drop the response. 3. Observe the app's behavior, then trigger the app's retry or recovery path. 4. Restore the network. 5. Query persistent orders for the intent. - **Expected:** The app reconciles the existing intent before retrying, there is exactly 1 order, and the confirmation shows its ID. - **Evidence:** Request log (including whether a status check preceded any retry), the persistent-order query, and a screen recording. - **Pass/fail:** Fail if there are 2 or more orders for the intent or the retry has no reconciliation step. - **Notes:** Needs manual setup and fault injection. **T-04 (priority 4): Activation interval sweep** - **Purpose:** Find the race window and test the Web and iOS guards at other timings. - **Platforms:** Web, Android, iOS. **Requirement:** R-03. - **Data:** Intervals of 0, 20, 80, 250 and 500 ms (Proposed fixture), 5 runs per interval per platform (Proposed fixture). - **Actions:** As T-01, varying the interval. - **Expected:** 1 order per intent at every interval. - **Evidence:** As T-01, plus actual intervals. - **Pass/fail:** Fail on any intent with more than 1 order. **T-05 (priority 5): Intent ID retention across retries** - **Purpose:** Verify the second half of R-03 on all platforms (S4). - **Platforms:** Web, Android, iOS. **Requirement:** R-03. - **Data:** The scenarios from T-01 and T-03. - **Actions:** Collect every order request for each intent, including retries. - **Expected:** The same `checkout_intent_id` on every request. - **Evidence:** Network request records. - **Pass/fail:** Fail if any request for the intent has a different ID. **T-06 (priority 6): Pricing regression** - **Purpose:** Preserve S1 parity. - **Platforms:** Web, Android, iOS. **Requirement:** R-01. - **Data:** DESK-01 × 2, SAVE10. - **Actions:** 1. Add the product. 2. Apply SAVE10. 3. Read the displayed lines at cart and checkout. 4. Submit and read the persisted total. - **Expected:** Subtotal 80.00, discount 8.00, shipping 5.00, tax 0.00, total 77.00, persisted total 77.00. - **Evidence:** Screenshots (visual only) plus the persistent-order row. - **Pass/fail:** Fail on any difference. - **Notes:** Automatable. **T-07 (priority 7): Empty address blocks submission** - **Purpose:** Preserve S2 parity. - **Platforms:** Web, Android, iOS. **Requirement:** R-02. - **Data:** Address line 1 empty, other required fields valid. - **Actions:** Submit, then query orders. - **Expected:** Submission is blocked with the address message, 0 order requests and 0 orders. - **Evidence:** Screenshot, request log, order query. - **Pass/fail:** Fail if any request or order appears. - **Notes:** Functional. Screen-reader announcement and focus handling need manual assistive-technology validation (coverage gap). **T-08 (priority 8): Whitespace-only address line 1** - **Purpose:** Boundary check on R-02. - **Platforms:** Web, Android, iOS. - **Data:** Address line 1 = spaces only (Proposed fixture). - **Expected:** Undefined. - **Status:** **Blocked pending rule confirmation (F-03).** No pass criterion is invented. **Coverage gaps:** Accessibility, viewport and text-scaling variation, back navigation and deep links, background/resume, and session expiry are not covered. They are outside the stated focus areas or lack supplied rules. The product page and cart interactions beyond pricing are also not tested. ## 6. Coverage and release handoff **Counts (this matrix only):** - Applicable cells N = 6 scenarios × 3 platforms = **18**, with no N/A. - Pass P = **12** (S1 ×3, S2 ×3, S3 ×2, S4 ×1, S5 ×3). - Fail F = **1** (S3 Android). - Unresolved = **5** (S4 Web and iOS, S6 ×3). - Execution coverage = (12 + 1) / 18 = **72.2%**. - Pass rate = 12 / 13 = **92.3%**. The pass rate is dominated by happy-path cells and says nothing about recovery, which is entirely unassessed. It should not be read as overall quality. **Release recommendation (this fictional exercise only): Hold.** F-01 is a known blocking order-integrity defect on a critical-journey step, which justifies Hold despite incomplete coverage. The following gates are **Proposed** (not supplied): - T-01, T-02 and T-04 show 0 duplicate orders. - T-03 passes on all platforms. - F-02 and F-03 are decided by the product owner. This is not final release approval. **Proposed five-working-day triage and retest plan** (effort and capacity are Unknown, so only the testing is committed, not the fix): - **Day 1:** Run T-01 on all platforms and T-02 to separate client from server causes. Product owner starts on the F-02 rule. - **Days 2–3:** Run T-03 and T-04. Run T-05 alongside them. - **Days 3–4:** Retest any fix delivered. Delivery is a dependency, and **I cannot promise a fix by day 5** without effort or capacity evidence. - **Day 5:** Rerun T-06 and T-07 as regression, then re-count coverage and update the recommendation. **Next three actions:** | # | Action | Owner role | Dependency | Evidence to close | |---|---|---|---|---| | 1 | Run T-01 and T-02 on staging and decide client versus server cause for F-01 | QA analyst with backend support | Timing-controlled input and a staging replay tool | Order counts per intent and replay results | | 2 | Confirm the duplicate-request contract (F-02) and the whitespace and pending-state rules (F-03) | Product owner | None | Written rules, which unblock the T-02 response criteria and T-08 | | 3 | Run T-03 (interrupted response) on all platforms | QA analyst, with staging fault-injection support | Fault-injection capability | Request logs showing reconciliation before retry, and order counts |