One of the most interesting examples of a software "abuse case" came to me rather abruptly on an airplane flight from Las Vegas to Orlando in mid 2005.
Each seat in the airplane had a small touch screen monitor built into the head rest of the chair in front, and on this particular airline, passengers could watch a variety of television channels and play a few simple games. One such game looked remarkably similar to the classic strategy game Tetris, where players use their skills to manipulate falling blocks on a screen to try and form horizontal lines. I'm a big fan of Tetris; for a few months in 1998 I was borderline obsessed with it. I would start looking at everyday objects and start mentally fitting them together with other tings in the room to form weird line configurations. One of the options on this particular airborne version of Tetris was to alter the number of blocks one could see in advance on the screen before they started falling.
To give myself the biggest advantage in the game, I pressed the + control as many times as it would allow and got to the maximum value of 4. I then put on my "bad guy" hat on and asked: How *else* can I change the value in this field? Near my armrest was a small phone console; you know, the one where you can make very important calls for a mere $22 per minute. I noticed that the phone had a numeric keypad and that it also controlled this television monitor embedded in the seat in front of me.
I then touched the screen in front of me to highlight the number "4" in the options configuration shown in Figure 1. I tried to enter the number 10 into that field through the phone keypad with no luck: it first changed to the number "1" followed by the number "0". Frustrated, I then made the assumption that it would only accept single digit values. My next test case was the number "8"; no luck there either, the number didn't change at all. I then tried the number 5: success! '5' is an interesting test case, it's a "boundary value" just beyond the maximum allowed value of the field which was '4'. A classic programming mistake is to be off by 1 when coding constraints. For example, the programmer may have intended to code the statements:
0 < value < 5
When what actually got coded was
0 < value <= 5
I now had the software exactly where I wanted it, in an unintended state; the illegal value 5 was now in my target field. I then turn my attention back to the screen and hit the + button which, to my complete surprise, incremented the value to 6! Again, an implementation problem, the increment constrain probably said something like "if value = 4 do not increment." In this case, the value wasn't 4 but 5 so it happily incremented it to 6! I then continue to increment the value by pressing the + button until I get to 127 and then I pause for a moment of reflection. 127 is a very special number; it is the upper bound of a 1 byte signed integer. Strange things can happen when we add 1 to this value, namely that 127 + 1 = -128! I considered this for a moment as I kicked back a small bag of peanuts and in the interest of science I boldly pressed the + button once more. Suddenly, the display now flashes -128 just for an instant and then poof...screen goes black.
Poof...screen of the person next to me goes black.
Screens in front of me and behind me go black.
The entire plane entertainment system goes down (and thankfully the cascading system failure didn't spill over to the plane navigation system)!
After a few minutes of mumbling from some of the passengers, a fairly emotionless flight attendant reset the system and all was well. I landed with a new-found respect for the game of Tetris and consider this to be the most entertaining version of it I have ever played.
No comments:
Post a Comment