Adding three-year olds to the test team
My three-year old son, Ethan, loves to press "play" and "pause". He does this with the remote for the DVD and TiVo, and also any Windows program that has a play and pause button. He's always on the look out for these buttons, and even likes to draw them. The other day, I had just started up one of the media players I use. Ethan noticed the play button so, of course, he wanted to press it. I thought, "why not?" So I gave him the mouse and he started toward the play button. However, he missed, and ended up clicking on the "previous" button, the one that steps you back to the previous item in the playlist. The program immediately crashed with an access violation. My son, with a single click of a mouse, discovered a fatal flaw in this application.
It got me thinking, perhaps we should add three-year olds to the testing team for SSP. Ethan clicked on a button which made no sense to click on -- the program had just started up, what sense did it make to click the button to play the previous song? But there was no previous song. Apparently, it was so obvious not to click on the previous song button when there was no pervious song in the play list, that it escaped testing. Now, admittedly, SSP has had similar defects in the past, which helps to make my point. Being bound by constraints of what any tester deems as a logical use of a program may actually result in some blatant defects being overlooked. Who knows what random clicking of buttons might reveal. Plus, if I bring Ethan on to the test team, he could get a head start on saving for college!
On second thought, if I hired Ethan to be on the test team, he'd probably just end up spending valuable company time playing Diego.