No technical background needed. If you play the game and want to help make it better, this is for you. The detailed working documents live alongside this one on the QA home page. Written 2026-07-16 (task QA-UXGRID1).
Software rarely breaks with a bang. The dangerous failures are the quiet ones — the app looks fine while quietly doing the wrong thing, or nothing at all. Testing is the craft of making failures loud, fast and specific instead of quiet, slow and vague.
Our testing world has a small cast. Once you know them, everything else follows.
Here's the problem. Take one simple action: dragging a little asset chip from your account onto another player's. Whether that works can depend on… how many players are on the board. Whether your screen is tall or wide. Whether you're on a phone, a tablet, or a computer with a mouse. Whether you're dropping onto a neighbour or someone across the board. Whether the thing you're dragging is money or a collectible. Whether the board was just rotated. And so on.
Each of those is a dimension — an axis with a few meaningfully-different values. Ours are listed (and kept up to date) in a registry. The trouble: if you multiply the options together, this ONE action has 7,776 distinct situations. Test them all by hand? Absurd. Test just one and hope? That's how bugs hide.
The trick that tames the explosion is called pairwise testing, and it rests on a well-studied fact: the vast majority of real bugs are triggered by the interaction of just two factors — like "oval × tall screen" — almost never five at once. So instead of all 7,776 combinations, you pick a clever couple of dozen such that every pair of values gets to meet at least once. Think of seating a party so that every guest shares a table with every other guest at least once over the evening — you don't need every possible full seating plan, just enough rounds that every pair meets. Two dozen careful tests catch nearly everything eight thousand would.
On top of those, we always include the turning points — the values where behaviour changes shape. Six players fit on our board; the seventh causes scroll-wedges to appear. So "6" and "7" are always in the test set, because edges are where bugs live.
From those couple of dozen situations, a handful are cherry-picked for humans — the ones needing judgement and feel: is the everyday drag pleasant? Does the collectible's arc flight look right? Does "sticky" mode feel like a real board game? A person plays those once, blesses them, and they become the benchmarks.
Everything else runs automated: a robot browser performs the same drags in every remaining combination, checks the machine-checkable facts (did the chip land inside the lines? did the balance change? is anything hidden off-screen? did the animation actually stop?), compares screenshots against the blessed benchmark, and posts a green or red mark onto a shared results grid — journeys down the side, software versions across the top. One glance answers: what's been re-proven on today's version, and what's red.
If you're playing the game and helping test — formally or just by caring — the process is deliberately simple:
| You do | What happens behind the scenes |
|---|---|
| Play a short, named scene — e.g. "CHIPDROP-01: two players, tablet, drag some money to your neighbour" — and say whether it felt right | the flight recorder captures the diagnostics of your run; if you bless it, it becomes the benchmark other runs are compared against |
| Spot something odd and report it (the in-app feedback button) | your report carries its breadcrumb trail with it, so we can replay what you saw without asking you twenty questions |
| Nothing — just play normally | even ordinary play exercises the flows the robots also watch; unusual patterns surface on the grid |
And the promise in the other direction: when a bug you reported is fixed, it doesn't just get fixed — it gets a canary, so the thing that annoyed you once can't come back quietly. Several of our current canaries were born exactly this way. A sample, in plain words:
| The rule the canary enforces | The incident that taught us |
|---|---|
| Changing how a chip looks must never change where anything sits | toggling one innocent setting used to scatter every chip on the board |
| The walls the physics obeys must be the shapes you can see | the circle-vs-oval story above |
| Nothing may end up off-screen or hidden under the header | chips used to vanish past the screen edge on tall screens |
| Dotted connection lines must move with their chips | lines used to stay where they were first drawn while the chips wandered off |
| When the board settles, it must be still | chips used to tremble forever on some tablets |
| A button must not move between your aim and your tap | a signing screen once grew mid-tap and a click landed on the wrong thing — with real money on the line. The most important canary on the list |
All of this — the dimension registry, the test scenes, the canary catalogue, the strategy — lives in this QA folder inside the app itself, in two layers: data files (the actual lists, under proper change-tracking, so every edit to a test is as visible as every edit to the code) and web pages like this one that simply display them. When a bug is fixed, the fix and its new canary land in the same change — you can literally see them side by side in the history.
Want the working detail behind all this — the actual dimension tables, the worked example with its 7,776→25→4 derivation, the harness choices? Read the strategy document next. The company-wide QA overview (the backend robots, alerts and dashboards) is a separate read, maintained from the QA seat.