Starting the loop — testing and the build, working directly together.
You haven't heard from me yet. That changes today.
I've been testing the app heads-down to get up to speed on where it really stands. I'd like to start joining the Monday build meeting so my findings can reach you directly — and we fix things in days, not weeks. Here's who I am, what I've found, and how we work together from here.
First — hello
I'm the one who's been quietly testing the app.
Heads-down until now, on purpose — to understand our issues before adding noise.
I run the test harness and the coverage work — I've been living in the app's edges.
You may not have heard from me directly — until now my findings reached you through Marc.
I'm up to speed now. So let's make that feedback direct, and much faster.
Part one · the review
The test process, in one picture.
Adversarial safety harness — structured scenario suites that probe how the app responds when it matters most.
Functional testing — hands-on runs through the real app: does each flow actually work, end to end.
Coverage reporting — what's been exercised, what passes, and where the gaps still are — tracked over time.
Part one · the review · live
Let me show you — I'll share my screen and run one, live.
Faster to see it once than to describe it three times.
Four quick stops: the harness → one scenario end to end → the coverage report → a real bug reproduced. The devs see the rigor, not just hear about it.
The screenshots on the next slides are placeholders — swap in your real screens. They double as your fallback if the live run hiccups.
Demo · step 1 of 4
Open the harness.
Screenshot — the test runner / suite listreplace with your screen
Show: the 12 suites, 189 scenarios. Say:"This is what runs against every build."
Demo · step 2 of 4
Run one scenario — live.
Screenshot — a scenario running: input → response → scorereplace with your screen
Show: what goes in, what the app does, how it's scored — an everyday scenario, not a crisis. Say:"This is exactly how we judge whether a behavior is right."
Demo · step 3 of 4
The coverage report.
Screenshot — the coverage reportreplace with your screen
Show: what's exercised, what passes, where the gaps are. Say:"Here's where we're solid — and where we're still thin."
Demo · step 4 of 4
Reproduce a real issue.
Screenshot — a functional bug reproduced in the appreplace with your screen
Show: the exact broken behavior and the steps to see it. Say:"This is the kind of thing that reaches you directly, every week now."
Part one · the review
Why this matters — the value it's buying us.
Every issue caught here is one a family never hits.
De-risks the trial. The app is going in front of real people — testing is what makes that safe to do.
Turns "it feels off" into something fixable. Specific, reproducible findings the team can act on.
Compounds. Coverage that grows week over week is the quality story — and a real advantage.
Part one · the review
The validations — what we've checked, and where it holds.
189
adversarial scenarios exercised
12
test suites
—
functional flows verified (fill)
Safety behavior is exercised across 189 adversarial scenarios in 12 suites — probed, not assumed. On the functional side, the flows I've verified hold; the ones that don't are what we work in the loop below.
Wording is deliberate: adversarial coverage, not "clinically validated." We say what we've actually tested.
Part one · the review
Consistency — the same process, every time.
Repeatable. Same suites, same steps — results you can compare release to release, not one-off spot checks.
Reproducible. Every finding comes with the steps to see it again — no "works on my machine."
Trended. We can see whether quality is improving or drifting, not just today's snapshot.
Part one · the review
The loop already works — here's what shipped.
What I raised
What changed
Impact
—
—
—
—
—
—
—
—
—
Testing that feeds back into the build is worth far more than a report that sits on a shelf. This is proof it does — and the reason to make the loop tighter.
Fill with 3 real examples of suggestions you made that got implemented — this slide is the strongest argument in the room.
Part two · the change
Why I think joining you on Mondays would help.
Find it Friday, fix it this week, verified by Monday.
Findings reach the developers directly — not through a relay, not days later.
The distance between finding a problem and fixing it gets as short as it can be.
Part two · the change
A weekly rhythm where nothing lingers.
Test→Find→Report here→Fix→I re-verify→Close
And nothing silently regresses — because the fix comes back to me before it counts as done.
Part two · the change
Every issue arrives ready to act on.
What breaks — the exact behavior, in plain terms.
How to reproduce — the steps, so you see it in 30 seconds.
Severity — Blocker · Major · Minor, so we sort by what matters.
Why it matters — the user or trial impact, not just the bug.
Part two · the change
This week — the few that matter most.
#
What breaks
Reproduce
Severity
Impact
1
—
—
Blocker
—
2
—
—
Major
—
3
—
—
Major
—
4
—
—
Minor
—
Short on purpose — the handful blocking quality, not the whole list.
Part two · this Monday · ~60 min
Today's agenda.
1Hello + why I'm here· 5 min Who I am, and what we're starting together.
2Live demo — how the testing works· 20 min Screen-shared: the harness → one scenario → the coverage → a real bug.
3This week's top issues· 15 min The few that matter — repro + severity + impact.
4The loop we're starting· 10 min How findings reach you and get verified, every week.
5Prioritize + close· 10 min What gets fixed this week, and what I verify next.
Every week after this is lighter — re-test, top issues, prioritize. The full demo is a one-time kickoff.
Part two · the change
What "done" means.
No "fixed on my machine." No silent regressions.
Fixed = I've reproduced the original, run the fix, and it holds.
That's how the list gets shorter — and stays shorter.
Going forward
Why I think taking part regularly could be useful.
The closer I am to what you're building, the sooner my testing can turn into small fixes — and the fewer surprises reach the trial. If it's helpful, I'd like to keep taking part this way: you'd get quicker, clearer feedback from me, and I'd always have the context on what you're working on. ♥
Same side — helping make something the people who'll rely on it can trust.