Can Automated Testing Replace the Manual Method? Date:   Tuesday , December 29, 2009 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. Now the question arises, do all tests need to be manual? The answer is 'no'. There are some tests that can be run unattended that companies don't need to be concerned about having human supervision. Automation is very helpful in dealing with the combinatorial explosion of test cases that companies have to deal with. So, it does not make any sense that testers should go for automation or manual, but it seems to be encouraging that IDC has forecast a CAGR of 19 percent for discrete global testing services to reach 17.7 billion by 2013. According to Gartner, testing could make up to 25-40 percent of software budget.