A tester, who always looks to other fields for inspiration, asked his pilot friends how does automation work for them? They told him that some aircraft would be unable to fly without automation. Automation doesn't replace the pilot but the computer can help the pilot to fly the plane more safely and efficiently. The software tester decides to make a similar use of automation in testing. He wants to create test fixtures to do things with greater precision than is possible with humans.

On a similar note, in the last few years there has been plenty of debate on what should an organization opt for – automated testing (writing test code to test an application) or manual testing (using user interfaces to apply inputs manually). Automated testing seems to have earned both disgrace and respect. The disgrace comes from the fact that tests are code, and writing tests means that the tester has necessarily be a developer. Can a developer really be a good tester? Some can be good testers, while some others may not; but the fact is that bugs in test automation are a regular occurrence, which means that the testers will be spending significant amount of time writing code, debugging it, and rewriting it. Respect comes from the fact that one can write a single program that will execute an unlimited number of tests and find tons of bugs. Automated tests can be run and then rerun when the application code has been churned or whenever a regression test is required.

Speaking at the 9th Annual International Software Testing Conference (STC) '09 in Bangalore, Michael Bolton, Founder Partner of DevelopSense said, "There is a huge difference between checking and testing. Checking is a process of confirming and verifying and it can be done by machines. Testing, on the other hand, is an activity that requires humans to perform; a machine lacks emotions and hence will only do what we program it to do."

Some companies are quite satisfied with the developer testing his or her own work. Testing one's own work is generally thought of as risky since he or she is likely to overlook the bugs that someone not so close to the code will see easily. As soon as the developer says it's done they ship it. Danny Fought, who is the Founder of Tejas Software Consulting, believes that automated testing can only be used for regression testing. If an organization runs the same manual regression tests repeatedly, the automated tests can replace some of that effort, but they will add to the effort to maintain the tests, which is sometimes more than the work required to just running the tests manually. Some of the effort means that test failures from an automated test run must be analyzed manually. In an interview to Indic Threads, Fought says, "If anyone asks, can automated testing replace manual testing, the simple answer is 'no'."

The fact is that testing industry has been automating for years, one can even say for decades, and they still produce software that promptly fails when it gets on the desktop of a real user. This is because automation suffers from many of the same problems that the manual developer testing suffers from. It is run in a laboratory environment, not a real user environment, and they seldom risk automation working with real customer databases because automation is generally not very reliable.