Kids as Beta Testers: How an Orphanage Computer Lab Became My Personal QA Hell

Several years ago, I worked at an orphanage for a while (don't ask). My territory was the computer lab: a few battered desktops, some mismatched chairs, and a rotating cast of kids aged eight to thirteen.

The lab had official opening hours, and the rules were crystal clear: no computer use before or after the official opening hours.

And, of course, anyone who’s ever have to deal with children, knows this was a total fantasy.

Closing time was chaos. I’d shut down one workstation, turn around, and the one I’d just powered off would be booting back up. They wouldn’t leave the room, so I had to chase them out one at a time like a very underpaid nightclub bouncer. Management’s stance was simple: “It’s your responsibility.” Translation: Your circus, your monkeys.

But I was a software engineer. Surely I could automate this.

I wrote a small control program. From my own workstation - the “control server” - I would send a lockout signal to every machine. The lockout was a full-screen modal GTK window that required a password to dismiss.

I wanted to be nice, so I even added a 15-minute warning popup. In theory, it gave anyone doing real work time to save their files. In reality, the moment it appeared, the room erupted into a chorus of:

“Noooo! Not yet! Just one more level!”

But the system worked flawlessly… 

For exactly two days.

Then the kids discovered that if they disconnected the control server from the network by unplugging its CAT5 cable from the switch, the lockout command never reached the clients.

Problem solved - for them. For me, I was baffled about why I didn't have network connectivity at random times always around closing time. Then I saw the disconnected cable. How smart.

I fixed this by making the workstations ping the control server every few seconds. If they didn’t get a response, they locked immediately. That ended the cable-pulling and things went back to normal…

...not for long.  

Next, someone found a magic key combination that bypassed the modal screen entirely. I still don’t remember how - probably some obscure GTK / X11 quirk buried in some man page that no adult has ever the patience to fully read. I also don't remember how I patched this, but I did. 

The modal was now ironclad, but the whole system wasn't. 

The next attack vector was a clever application of social engineering. I naively used the same password for every machine. One kid would lure me over with a convincing excuse -“Sir, my screen is frozen”, while another watched me type the password over my shoulder. Once they had a partial idea of the password, they brute-forced the rest. Eventually, every machine was unlocked again.

Then I introduced a primitive one-time pad. Each workstation got a unique, random password at lockout, used only once. Shoulder surfing was now useless.

At last, peace. Closing time came, machines locked in unison, and the kids reluctantly shuffled out without trying to reroute Ethernet cables under the desks.

Not long after, my stint at the orphanage ended, and I moved on. But I left with one lesson I’ve never been able to use again:

If you need QA testers, use kids.

They will find—and exploit—every single edge case, loophole, and design flaw you didn’t even know existed.

Not because they’re trying to break your software, but because they’re just trying to win at something they perceive as an unfair (from their own perspective) game.

And that’s far more dangerous.