The 10-Second Perfect Score: Trust, Testing & Curiosity

The Anomaly

I’m part of the qabash.com community — a platform that offers free QA tools, courses, and a gamified XP system, including a daily quiz called Testathon. Five questions a day, tied to real QA and engineering concepts. Speed matters, accuracy matters more, and the fastest fully-correct submission takes the top leaderboard spot.

For a while, a pattern kept showing up that nobody could quite explain: a handful of participants were finishing all five questions, correctly, in 14 to 15 seconds.

Not just fast, but far faster than I could reproduce through normal human interaction. Five questions, one involving actual code, in less time than it would reasonably take to read and understand the questions, select the answers, and move through the quiz.

Most people shrugged it off as “some people are just quick.” I couldn’t.

Building a Baseline

The first instinct in QA isn’t to assume — it’s to measure. So I ran a control test on myself.

I opened the quiz, read only the first question, then stopped reading entirely. For the remaining four, I didn’t look at the question or the options — I just tapped an answer at random and hit Next as fast as physically possible, then submitted.

Result: 23 seconds, with two answers wrong.

That number mattered more than it looks. It meant that even a zero-comprehension, random-tapping path still took me 23 seconds. Yet other participants were submitting in 14 seconds with a perfect score. That was far outside anything I could reproduce through normal human interaction.

Now I had something more useful than a suspicion. I had a measurable anomaly.

That’s when this stopped being “huh, weird” and became an actual investigation.

Finding the Gap

With a target to hunt for, I started probing the mechanics of the quiz itself rather than the questions.

The first thing I tried was simple: skip a question without answering it, using Next. It worked. There was no validation and no block — the app happily let me move through all five questions without selecting a single option.

That one behavior was the seam. I pulled on it.

I started the quiz, read each question without answering, and tapped Next through all five. I didn’t submit. Instead, I refreshed the page because I wanted to see what would happen to the quiz state – would it keep me where I was, or would it take me back to the beginning! After the refresh, I found that I could start a fresh attempt, now armed with the knowledge of all five questions and their answers.

I selected the correct answers, hit Next, repeated the process, and submitted quickly.

Result: full marks in 10 seconds. On a second run, 7.

The exploit wasn’t clever code or a sophisticated security hack. It was a simple logic gap. The application trusted that “still working through the quiz” and “starting over” were effectively separate states, while the backend had no reliable way to distinguish between them. At the same time, the browser was being trusted with information that should have been controlled by the server.

The important part wasn’t just that I had found a way to reproduce the unusually fast scores. I now had a concrete explanation for an anomaly that initially looked almost impossible.

A Public, Honest Disclosure

Once I could reliably reproduce it, I did two things: filed it through QABash’s official “Report a Bug” channel, and separately posted about it in the community group — framed lightly, as “I think I found a feature,” rather than as an accusation aimed at anyone.

That framing mattered. The people submitting in 14 seconds weren’t necessarily acting maliciously — they may simply have stumbled onto the same shortcut I did, perhaps by accident or curiosity, and found that it worked. Nobody had broken into a server or exploited a vulnerability in the traditional security sense. They had found a door the application had left open and walked through it. The problem was with the door, not necessarily with the people who noticed it.

Once I posted it, several community members tried it themselves and reproduced it almost immediately. Ironically, that became some of the strongest evidence I could have handed the team. A reproducible issue that multiple independent people can confirm is worth far more than one person’s word.

It also reinforced something I think is important in QA: finding a bug and communicating a bug are two different skills. A technically correct finding can still be poorly handled if the report immediately assigns blame. Focusing on the behavior, impact, and reproduction makes the conversation much more productive.

Root Cause, Properly Diagnosed

The Community Council, Ishan Dev Shukl, picked it up immediately, reproduced it with the steps I provided, and we worked through fix directions together. His eventual root-cause writeup nailed the real issue, and it’s worth sitting with because it’s a pattern that shows up far beyond quiz apps.

The server was trusting the client for two things it should never have trusted it for — elapsed time and attempt state. Refreshing the page reset the attempt locally, with no reliable way for the backend to distinguish “still in progress” from “starting fresh.” And because only the final submission was checked, a fast second attempt looked entirely legitimate from the server’s point of view.

That’s the real lesson under the lesson: the client is a rendering layer, not a source of truth. Anything that affects fairness, security, scoring, or important application state — time, progress, attempt state, completion status — has to be owned and verified server-side. The moment you let the browser become the record-keeper for something important, someone will eventually find a way to manipulate that assumption.

The Fix

The immediate, live fixes were straightforward but addressed the underlying behavior rather than simply blocking the exact sequence I had discovered.

The Next button is now disabled until the current question is answered. Each answer is locked in server-side the instant Next is pressed, so there is no going back and changing the answer. Quiz attempts are now resumed rather than restarted, meaning that refreshing, closing the browser, or logging in from another device reconnects the user to the same attempt, with the original start time intact. Most importantly for the leaderboard, elapsed time is now calculated and verified server-side instead of being trusted from the client.

Coming next are randomized question sets pulled from a larger pool instead of a fixed daily five, along with randomized answer-option ordering. Those changes help close memorization-based shortcuts as well, rather than focusing only on the specific path I discovered.

What This Taught Me (Again)

A few things this reinforced, ones worth revisiting no matter how many years you’ve been doing this.

• Trust your baseline, not your assumptions. “That seems too fast” only becomes actionable once you’ve measured what “fast but honest” looks like. The 23-second baseline turned an observation into evidence.
• A bug report is more persuasive with a number attached. “This feels off” can easily get a shrug. “My fastest zero-comprehension path is 23 seconds, while perfect submissions are appearing in 14” gives people something concrete to investigate.
• Good disclosure protects people, not just systems. Reporting what you found without immediately blaming the people who benefited from it kept the conversation constructive. The goal of a bug report should be to help the product and the people building it understand what happened.
• Root cause thinking beats symptom-patching. The fix wasn’t “block the exploit I found.” It was “fix the trust boundary that made the exploit possible in the first place.” That approach is much more valuable because it can close off variations of the same problem before they are discovered.

And finally, curiosity doesn’t retire. More than ten years into QA, the instinct that mattered most here wasn’t a tool or a framework. It was the same “wait, how?” that probably got many of us into this field in the first place.

The Happy Ending

Ishan shipped the fix, wrote up the root cause publicly, and credited the report by name in the community. Then came a genuinely lovely surprise: 5,000 XP, 30 days of streak immunity, and a gift voucher — with a public note encouraging others to report what they notice too.

That recognition meant more to me than the rewards themselves. It reinforced the idea that curiosity can create real value, even when it starts with something as small as a number that doesn’t add up.

That XP also put me one step away from QABash’s Ambassador tier — a status earned not through routine activity, but through a single afternoon of stubborn curiosity about a number that didn’t make sense.

If there’s one line I’d want a reader to leave with, it’s this: the best bugs aren’t always found by trying to break things. They’re found by noticing when something doesn’t quite make sense, and refusing to let it go until it does.

Notice it. Measure it. Reproduce it. Find the root cause. Communicate it responsibly.

And, if you’re lucky, help make the product better along the way.

Update: Since this article was first published, that XP crossed the threshold — I’m now officially an Ambassador on QABash.

Bookmark