Manual Testing The easiest way to verify that a feature has been implemented is also the most literal: run the application and attempt to trigger the behavior just like any normal user would do. For the purposes of this chapter, we’ll refer to this approach—and any other approach that involves human verification—as manual testing, and it has plenty of negatives associated with it.
Humans are error prone First and foremost, manual testing is based on human judgment, and humans are notoriously error prone. While a human will eventually need to make the final judgment call to say whether a feature has been implemented correctly or not, most human judgment up to that point is subjective, sometimes to the extent that it becomes impossible for a human to tell whether something works or not. For instance, even when you are awake, alert, and ready to spot even the smallest bug, will you ever be able to tell the difference between the string value 1 and the int value 1 just by looking at it on the screen? As any developer who’s done any kind of bug fixing knows, these kinds of issues may sound innocuous, but they can end up meaning the difference between an application that works and one that fails miserably.
Computers are more efficient Next comes the matter of efficiency. When a human user tests an application, he is not instantiating classes and calling methods; he is interacting with the application through some kind of UI. The user must use the application as it was intended, since changing the application to allow for easier testing may jeopardize the results of the test, or those changes may even introduce bugs themselves. This often means that a single test to reproduce a particular scenario can involve many steps that must be followed correctly and in a specific order, making manual testing quite tedious and laborious, and making the chances of human error even greater. Computers are much more efficient at performing such procedures.
Manual testing takes time And then there is the biggest issue: manual testing takes time—human time that could be better spent doing something else. Consider, for instance, a developer implementing a feature and having to stop after each small change she makes to (correctly) execute a series of potentially complex steps in order to verify that change. Now consider what happens if that small change doesn’t work and another change needs to be made. And another, and another…
344 | Chapter 17: Automated Testing
www.it-ebooks.info