Testing Tales: Early Lunch

He went to lunch early again.

My fellow cube-mates and I were still working on our daily test pass. We efficiently, and carefully walked through line-after-line of test cases in a database. We were manually testing, looking for the unexpected, and running automated scripts — dutifully marking each test as “pass” or “fail” and sometimes filing bug reports.

He was a social guy, but every day he would head to lunch before everyone else. Why? What was he doing at lunch that he didn’t want anyone else to see? Was the cafeteria food better when it first opened?

We weren’t in any rush to lunch. We would wait for everyone else to finish their test passes. We’d then meander on the little path through the trees, join him at a table, and geek out for a bit over some cafeteria food and free sodas. Not a big deal, that was the routine. No one rushed, except for him.

He had had about the same number of tests as everyone else. Was he just better? Did he have a trick to go faster? He and his lead had their own big dedicated offices, right next to each other. She also noticed he seemed to be finishing test passes earlier than everyone else, so of course, she assigned him some new tests to balance the workload and get the testing done earlier.

Still, he would get to lunch early.

I’m not sure who it was, but we asked him how he did it. We wondered if he was doing something smarter. He just shrugged it off as if he didn’t understand the question.

All those little passes/fails were recorded. I was charged with keeping the database ‘healthy’ — not an easy task with Access databases. The team had logged enough results that the database needed to be periodically compacted. If it wasn’t compacted, the thing would slow down and then start to throw errors. While compacting, I noticed that everyone’s test logging events were a pretty consistent stream of time stamps — logging a test every minute or two and evenly distributed. But our early lunch friend, well he would batch his test results. He’d log them all at once. That was his secret! Maybe if you run a lot of tests in a row, then log them all at once, it takes less time than going back and forth to execute the test than log each result individually. A little faster on every test case and, voila, you are off to lunch a little earlier.

I casually shared this hypothesis with his test lead and said I was going to see if it worked. She was skeptical. While I was trying this out on the next test pass, she was strolling past his office peeking at his computer screen. Instead of seeing testing, there were some games running on the background of his screen.

This wasn’t entirely unusual, the work environment was long hours, but flexible. And, we had free access to a lot of games that the company made in other buildings. He was so good that he was able to play them a bit in the background while running through test cases. Even with that distraction, he still made it to lunch earlier than everyone else.

In hindsight, it seems obvious, but this guy didn’t find many bugs.

He was gone the next day. His test cases were divided among everyone else. We all got to lunch a little later than usual.

— Jason Arbon, a Tester