Interview objective: Agree acceptance criteria before procurement, without presenting a small sample as nationwide assurance.
Put this to: Chris Gallo, the publisher’s QA lead and a browser-testing specialist.
Why it matters to buyers: Chrome’s own documentation describes Device Mode as an approximation: the code still runs on a desktop or laptop, not on the simulated mobile device. It recommends testing on actual mobile hardware when necessary. (developer.chrome.com)
Draft framing — a good answer should cover:
| Dimension | Proposed pilot requirement |
|---|---|
| Content | Essential titles plus a declared sample across studios and launch implementations |
| Devices | Named real devices and browsers; emulated tests labelled separately |
| Conditions | Declared network, cache, consent and storage states |
| Locations | Authorised test locations, with no claim about untested locations |
| Outcomes | Readiness, interaction, failures, denied access and fallback behaviour |
| Repetition | Agreed repeat runs and retests after material changes |
Sharp follow-up: “Which failures would block acceptance, and which would permit a limited launch with exclusions?”
Buyer output: A signed-off HTML5 slot embed performance testing checklist and an exception register.
Set thresholds from the buyer’s requirements and pilot evidence. Do not invent an industry-wide launch-time target or availability guarantee. Report failed and indeterminate runs alongside timing distributions so successful sessions cannot conceal a poor overall launch rate.
Expert quote — awaiting interview: [Approved quotation and attribution.]