There's an old QA joke:
| "QA Engineer walks into a bar.
|
| There are “edge cases”, “corner cases”, and “boundary conditions.” While there is good reason to make sure of these cases, software development has come quite a long way over the last 40 or 50 years. Users aren't pecking away at a terminal attached to a mainframe where every keystroke means something to the computer. In web applications, there are ways to sanitize the input. Usually before it ever gets anywhere near the servers processing that input. Even Intranet and desktop applications can manage user input, so most of these cases and conditions can be covered easily with client-side and server-side validation. If the programmer validates that the input is an integer between a minimum of 1 and a maximum of 10 and that beer, whisky, and appletinis are the only options, then creating and running a test for conditions outside of that narrow range that the programmer has limited the system to accept as inputs are a very serious waste of time. To illustrate my point, “The Validated Bar” passes all your edge cases and boundary conditions. Opening night, 4:00 p.m., the bar opens, the first customer through the door comes in and asks the bartender, “Where’s the bathroom?” The bartender sets fire to the place and walks out. There was no account for actual usage. Testing only covered the test cases that the programmers already validated against. The moral of the story: Testing is not an exercise in what a computer does. It’s about the humans using the computer. |  |
