Automated Testing Vs Manual Testing

[lokeshm]

Is it possible to completly automate the testing process? Will automated testing fully takeover manual testing? Any answers.... Any thoughts....

[jenicks]

Originally Posted by lokeshm

Is it possible to completly automate the testing process? Will automated testing fully takeover manual testing? Any answers.... Any thoughts....

Its not the question of which over takes. when u take the testing as a big aspect. Manual testing is always there. Any product which is stable by 50 to 60% can only be automated. Other wise automation is not possible. Both testing are like two horses in a chariot you can say this is good thats good.
We can even say manual testing and automation testing are two phases of testing once manul is over then they will go for automation.. and it depends upon the project too..

[lokeshm]

jenicks,

Its nice to read your reply, thanks for such precise answer.
Thanks again.

[QualityVista]

I agree with genicks. You should go for Automation when your product is quite stable. This way, automated testing can be best suitable for Regression Testing of a product.

Cheers,

[renurawal]

For manual testing time should be proper, and human thoughts and skills to be effective but in Automation testing all should automated and short project is good for automation testing. For large projects manual testing is good.

[moonlight]

When Test Automation Makes Sense

Let’s start with the tests that ideally are automated. These include:

* Regression and confirmation. Rerunning a test against a new release to ensure that behavior remains unbroken—or to confirm that a bug fix did indeed fix the underlying problem—is a perfect fit for automated testing. The business case for test automation outlined in Software Test Automation by Mark Fewster and Dorothy Graham is built around this kind of testing.

# Monkey (or random). Tests that fire large amounts or long sequences of data, transactions, or other inputs at a system in a random search for errors are easily and profitably automated

# Load, volume, and capacity. Sometimes, systems must support tremendous loads. On one project, we had to test how the system would respond to 50,000 simultaneous users, which ruled out manual testing! Two Linux systems running custom load-generating programs filled the bill.

# Performance and reliability. With the rise of Web-based systems, more and more automated testing is aimed at looking for slow or flaky behavior on Web systems.

# Structural, especially API-based unit, component, and integration. Most structural testing involves harnesses of some sort, which brings you most of the way into automation. Again, the article I wrote with Greg Kubaczkowski, "Mission Made Possible" (STQE magazine, July/Aug. 2002), provides an example.

Other tests that are well-suited for automation exist, such as the static testing of complexity and code standards compliance that I mentioned in the previous article. In general, automated tests have higher upfront costs—tools, test development, environments, and so forth—and lower costs to repeat the test.

When to Focus on Manual Testing


* High per-test or maintenance costs are one indicator that a test should be done manually. Another is the need for human judgment to assess the correctness of the result or extensive, ongoing human intervention to keep the test running. For these reasons, the following tests are a good fit for manual testing:

# Installation, setup, operations, and maintenance. In many cases, these tests involve loading CD-ROMs and tapes, changing hardware, and other ongoing hand-holding by the tester.

# Configuration and compatibility. Like operations and maintenance testing, these tests require reconfiguring systems and networks, installing software and hardware, and so forth, all requiring human intervention.

# Error handling and recovery. Again, the need to force errors—by powering off a server, for example—means that people must stay engaged during test execution.

# Localization. Only a human tester with appropriate skills can decide whether a translation makes no sense, is culturally offensive, or is otherwise inappropriate. (Currency, date, and time testing can be automated, but the need to rerun these tests for regression is limited.)

# Usability. As with localization, human judgment is needed to check for problems with the facility, simplicity, and elegance of the user interface and workflows.

# Documentation and help. Like usability and localization, checking documentation requires human judgment.

Wildcards

In some cases, tests can be done manually, be automated, or both.


* Functional. Functionality testing can often be automated, and automated functional testing is often part of an effort to create a regression test suite or smoke test. However, it makes sense to get the testing process under control manually before trying to automate functional testing. In addition, you’ll want to keep some of the testing manual.

# Use cases (user scenarios). By stringing together functional tests into workflows, you can create realistic user scenarios, whether manual or automated. The trick here is to avoid automation if many workflows involve human intervention.

# User interface. Basic testing of the user interface can be automated, but beware of frequent or extensive changes to the user interface that can incur high maintenance costs for your automated suite.

# Date and time handling. If the test system can reset the computer’s clocks automatically, then you can automate these tests.

Higher per-test costs and needs for human skills, judgment, and interaction push towards manual testing. A need to repeat tests many times or reduce the cycle time for test execution pushes towards automated testing.