Gibbon Testing

In my first programming job, I worked for a small company (under 10 employees in total). We had no Software Testers, and we definitely didn’t have any testing process. I don’t recall any automated tests either; I certainly didn’t know how to write them at the time (not even Unit tests).

When I finished my work, I informed the Senior developer, and I would upload the software to a touch-screen Terminal. He would casually play about with my new features. If he was happy, then the CEO would do similar tests; just casually explore and verify I had done what I claimed. Once he seemed happy, he did his final test: “The Gibbon Test”.

You could say this is some kind of performance testing, and also testing out multiple features in a short amount of time. What did the testing involve? Well, just frantically bashing on the screen.

I’m not sure how serious he took the testing. I mean, obviously it was a joke and we all laughed watching him do it. However, on reflection, I think it is actually a good idea – definitely a good one to do last after you perform all your serious tests.

With certain applications, the user could be frustrated and hit the screen randomly. Your program should be resilient to such abuse. I think a good example would be some kind of gambling game. When the user loses their money and hits the screen in frustration – the application shouldn’t crash, or take ages to respond. It should be ready for the next person to use.

Leave a comment