QA Bug Portal
File bugs from your laptop while you play on your phone.
Each tester has their own code, which identifies you. No name needed. The code is stored only in this browser.
File bugs from your laptop while you play on your phone.
Each tester has their own code, which identifies you. No name needed. The code is stored only in this browser.
The more detail you give, the faster we can reproduce and fix it.
Goal: file actionable bug reports that give devs enough to reproduce + fix without follow-up questions.
Use the Report form: summary, category, game mode, and a screenshot. Build, platform, device, and OS are required, but they are remembered from your last report and pre-filled, so you set them once. The portal stamps the ID, the timestamp, and your name (from your access code) on submit. There is no spreadsheet row to fill.
While playing, a four-finger tap grabs a screenshot of whatever is on screen and opens this portal with that shot already attached and the form ready, so you can file the moment you see something wrong.
My reports lists every bug you filed with its live status and the build it was fixed in. All reports shows everyone's bugs, search it before filing so the same thing is not logged twice.
When a dev marks your bug Ready for QA it appears under Needs verification. Reinstall the named build, retest, and mark it Fixed or Not fixed. You have the final say, not the dev.
Every confirmed bug earns points by severity and rarity, every fix you verify earns a point, every playable you fully check (answer every item) earns a point too, and each live game mode you actually play that day is worth 2 points. Your Hunt tracks your rank, streak, and badges; the Leaderboard ranks the whole team.
Crux is a daily-puzzle iOS app (TestFlight only right now). One new puzzle per mode per day, reset at midnight UTC.
Currently 49 live puzzle modes + a few non-game surfaces (Daily Coin Toss, Daily Wager, Mystery Box, Daily Wheel, Season Pass, Crux Plus subscription).
Three currencies:
For testing convenience, all players currently have ~100k coins / 10k gems / 55 bolts.
Crux has a deliberate, calm tone. Voice contract violations should be filed.
If a string feels off, it usually is. File a Minor with the exact string + screen + voice rule it violates.
Open any popup, try X button, backdrop tap, system-back gesture, swipe-down, leave it open for ~15s. Every modal should be escapable from every state (loading / success / error).
Watch your gem/coin counter after every hint spend, claim, purchase. It should match server state immediately. File if the displayed number disagrees with what just happened (going negative is a CRITICAL).
T1 / T2 / T3 hints should each do something distinct + visible. If a tap closes the modal but nothing happens on the board, file. If buying the same hint twice charges twice but reveals the same letter, file.
Mid-puzzle hit back, leave the app, force-quit. Come back. Your progress (typed letters, revealed letters, timer offset) should restore exactly.
Claim a reward, does the lobby card update? Solve a puzzle, does the archive show "completed"? UI should reflect server state without needing a force-restart.
Double-tap buy buttons, mash hint pills, two-finger tap on counters. Should never double-charge or leak state.
Every mode has a 3-step tutorial. Check the illustration actually shows what the text describes (we've shipped wrong flags / missing drag indicators recently).
Top bar / chrome / modals on iPhone SE (narrow) AND iPad (wide). Common: pills overlap, scrollbar overlaps grid, buttons clip to bottom edge.
Don't just test on one device, bug coverage depends on the matrix:
States worth deliberately triggering:
| Severity | What it covers |
|---|---|
| Critical | Crash, unplayable mode, blocked progress, data loss, broken currency or purchases |
| High | Mode mechanic broken (hint does nothing, button no-op, wrong scoring), tutorial misleading |
| Medium | Noticeable functional or visual defect with a usable workaround |
| Low | Voice violation, copy typo, color contrast, small layout or polish issue |
The form captures most fields for you. Spend your effort on the parts only you can write: the summary, the steps, and what you expected versus what you saw.
A few habits make your reports faster to file, easier to fix, and worth more points. None of this is hard. It just adds up.
Type the description on a laptop, not the phone. You can write a clear, detailed report much faster with a real keyboard, and detail is the part that matters most. Play on the phone, file from the laptop.
Found something while playing? Tap with four fingers anywhere inside the game. That grabs a screenshot of what is on screen and opens this portal with the shot already attached and the form ready. File the moment you see the bug, before the details fade.
Write what happened in plain words and fill in the other fields. A clear written report is the single most useful thing you can give a dev. This is what gets a bug reproduced and fixed without a back-and-forth.
A screenshot confirms what you saw and pins down the screen and state. Attach one whenever it helps. It backs up your words, it does not replace them.
Only attach a video when text and screenshots truly cannot convey it, for example a timing or animation bug where the motion is the problem. Do not lead with video. It is slow to record, slow to review, and usually unnecessary.
Completely filling out all the fields earns a bonus. A complete report is easier to triage and score, so it is worth more to you and to the team.
Four fields are required and autofill from your last submission so you are not retyping them every time: Build / version, Platform, Device, and OS version. They carry over, so just glance at them and confirm they are still correct rather than typing them again. The summary, category, mode, steps, expected, and actual always start fresh.
A precise, specific title. Clear numbered steps to reproduce. A sensible severity guess. Expected versus actual stated plainly. The closer your report is to "a dev could fix this without asking you anything," the higher it scores.
The build number is the most common source of wasted time. A wrong build causes false "still broken" and "cannot reproduce" loops, because the dev checks a different build than the one you saw the bug on. Enter the build you actually had in front of you.
It is in TestFlight next to the app, and in the app's own Settings or About screen. It looks like 1.4.2 (231): the version, then the build number in parentheses. Copy it exactly.
When the same bug is filed more than once, we keep the earliest report as the main one and mark the newer ones as duplicates of it. The earliest report is the canonical report, and its reporter keeps the credit. That is why checking All reports and filing early both matter.
A report marked as a duplicate is closed for you: you cannot verify it, because it is tracked and verified on the main report instead. Open it and it will point you to the main one. This keeps one bug in one place rather than split across several threads.
A duplicate earns no leaderboard points, so the same bug filed several times never multiplies anyone's score. The way to climb is to find new bugs, not to re-file known ones.
Use the Hide duplicates toggle on All reports to collapse the merged duplicates so you see one row per distinct bug. Open a main report to see who else filed it and when, without leaving the list.
If your report was marked a duplicate but you believe it is actually a different bug, you can refute the duplicate from your report and say why. A developer will take another look and either unmerge it or explain the match.
Check All reports first and search the summary. If you do not find it, file it. A near-duplicate is better than a missed bug, and devs can merge duplicates.
File it anyway with everything you saw, and note that it was intermittent and you could not reproduce it on demand. An intermittent bug is still a real bug, and your notes may be the only clue.
A quick circle or arrow on the problem area helps, but it is not required. A plain screenshot plus a clear description is fine.
If something feels wrong or confusing, file it or ask in the dev channel. Sometimes it is intended, but a confusing design is worth knowing about too.
Top bug hunters, ranked by severity-weighted points. Playing a live mode that day is worth 2 points. Climb the board.
Every tester, side by side. See who leads each metric at a glance.
A direct line to the orchestrator. Ticks show delivery: one for sent, double gray once it is read, double blue once work has started.
Propose a game improvement. These are reviewed by the developer, and only approved ones get built. This board is separate from bug reports.
Some things that look like bugs are actually intended. This page explains those decisions and the reasoning behind them. Have a read before filing, so you know what is by design and what is worth reporting.
Document an intended behavior so testers understand it. Plain language, no jargon.
Share an observation or something that felt unclear (like "the streak system is unclear"). This is for feedback, not strictly a bug or a feature request. The developer reads each one and decides what to do with it.
These are the little playable ads for our games. Open each one, give it a quick try, and tick off what works. If something is off, tap Fail and add a quick note. Your checks go straight to the developer.
Notes testers left on the playable ads, gathered into one list to work through. Read the note, fix the creative, then tap Mark fixed to clear it from the queue.
Everything the testers rated and checked on each playable, gathered together and ranked with the best-rated first. The top rows are the ones to push to AppLovin and Meta first. Tap a card to see each tester's checks and notes.