define expected behavior
Before implementation, I sit with the developers and pin down how the feature should behave and feel. If we can't write it down, we're not ready to build it.
i'm the QV point of contact for my pod. this is where that starts.
from feature brief to ship-ready
step 01
step 02
step 03
step 04
step 05
step 06
how a feature gets verified
Quality isn't a phase at the end. This is the loop I run on every feature my pod owns, every sprint, on an unannounced AAA title.
design the coverage
Test plans, cases, and stories in JIRA and Confluence with entry and exit criteria, built to be reusable across the feature's whole lifecycle, not thrown away after one pass.
review against intent
As work lands I review it against the design intent we agreed on, flagging risk areas ahead of sprint deliverables instead of after them.
run the passes
Functional, regression, smoke, and sanity passes across builds. Different questions, different depths, same goal: know exactly what state this build is in.
triage & escalate
Defects logged with clean repro steps and honest severity, routed to the owning dev, and blockers escalated to resolution before milestone dates. I report my pod's quality status up to the Development Director.
prove release readiness
Certification and submission support against first-party requirements. On Madden NFL 26, that meant platform validation for the Nintendo Switch 2 launch.
the parts nobody sees
the craft, up close
Four pieces of the job that separate senior QV from button-mashing, with the receipts to match.
switch 2 certification
Shipping on a brand-new console means meeting Nintendo's submission requirements with zero room for interpretation. I provided platform validation and first-party certification support for Madden NFL 26's Switch 2 launch: compliance passes, submission prep, and release readiness.
launch title on new hardware. no pressure.
engine-level access
I work with engine and build access across Frostbite, partnering with developers on investigation and minor fixes. I review in-engine assets, using working knowledge of Maya and Substance Painter to judge models and visual systems against the intended bar.
qa living inside the engine. rare breed.
ai-assisted tooling
Our leadership encourages hands-on AI adoption, and I ran with it. Working in VS Code with GitHub Copilot, I build internal tools that make my QV team faster, starting with test design briefs: slow, manual, and inconsistent, until tooling turned them into a repeatable pipeline that other QA teams now use.
built it for my pod. it escaped.
visual quality ownership
On Madden NFL 26 I owned Presentations & Visuals: broadcast cameras, cinematics, and polish on one of the most fan-scrutinized areas of the game. My photography background is why the team trusted me to judge composition, lighting, and readability deliberately.
the pretty stuff is measurable. fight me.
a well-written ticket saves an hour. a vague one costs a day.
anatomy of a great bug
A fictional example, real standards. This is the bar I hold my pod's reporting to, and every part of it earns its place.
CAM-1042
Severity B
Repro 8/10
Title[Presentation] Replay camera clips through mascot during touchdown celebrations
Build2026.04.18.1132 · PS5 · Retail-equivalent
Repro steps
- Score a touchdown with any home team
- Let the celebration play uninterrupted
- Watch the auto-replay's low sideline angle
ExpectedReplay camera frames the celebration; collision keeps it clear of characters
ActualCamera passes through the mascot's torso for ~20 frames before recovering
Evidencevideo attached · 0:12, timestamped
NotesOnly reproduces with mascots taller than ~2.2m; suspect celebration volume bounds. Related: CAM-0977.
- 01Searchable title. Area first, then action, then result. Six months later, someone will find this in triage by keyword. That's on purpose.
- 02A repro rate, not a vibe. "8/10" tells the engineer how hard it'll fight back. "Sometimes" tells them nothing.
- 03Minimal steps. Three numbered steps, no fluff. Every extra step is a place the repro can break.
- 04Expected vs. actual. Kills the "working as intended?" debate before it starts. This is design intent, written down.
- 05Evidence, timestamped. Video or it didn't happen. The timestamp saves the dev from scrubbing.
- 06Investigation notes. The root-cause hunch and the related ticket turn a report into a head start.
the room where design gets decided
read the case study
playtest production
The full story of how I run team-wide playtests for a large cross-discipline dev team, from build readiness to sessions with EA's most senior leadership, lives in its own case study.
running playtests for a full AAA dev team
Build candidate selection, smoke passes, blocker triage, hosting and moderation, and the near-miss that taught me process beats heroics. Context, numbers, and lessons included.
the part where you email me
let's raise the quality bar
Open to senior quality verification and QA opportunities where quality is treated as a craft, not a checkbox.
want the whole picture? the main site lives at chrislacroix.dev