It has been suggested that this article be merged with Test execution engine. (Discuss) Proposed since February 2010.
It has been suggested that this article be merged with Test automation framework. (Discuss) Proposed since March 2010.
Compare with Manual testing.

In software testing, test automation is the use of special software (separate from the software being tested) to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions.[1] Commonly, test automation involves automating a manual process already in place that uses a formalized testing process.

Overview

Although manual tests may find many defects in a software application, it is a laborious and time consuming process. In addition, it may not be effective in finding certain classes of defects. Test automation is the process of writing a computer program to do testing that would otherwise need to be done manually. Once tests have been automated, they can be run quickly and repeatedly. This is often the most cost effective method for software products that have a long maintenance life, because even minor patches over the lifetime of the application can cause features to break which were working at an earlier point in time.

There are two general approaches to test automation:

Test automation tools can be expensive, and are usually employed in combination with manual testing. Test automation can be made cost-effective in the long term, especially when used repeatedly in regression testing.[citation needed]

In Automation Testing the test Engineer or Software Quality Assurance person should have coding knowledge as they have to write down the test cases in form of code which when run and give output according to checkpoint inserted in it. Checkpoint is the point which is inserted to check any scenario.

One way to generate test cases automatically is model-based testing through use of a model of the system for test case generation but research continues into a variety of alternative methodologies for doing so.[citation needed] In some cases, the model-based approach enables non-technical users to create automated business test cases in plain English so that no programming of any kind is needed in order to configure them for multiple operating systems, browsers, and smart devices.[2]

What to automate, when to automate, or even whether one really needs automation are crucial decisions which the testing (or development) team must make. Selecting the correct features of the product for automation largely determines the success of the automation. Automating unstable features or features that are undergoing changes should be avoided.[3]

Code-driven testing

A growing trend in software development is the use of testing frameworks such as the xUnit frameworks (for example, JUnit and NUnit) that allow the execution of unit tests to determine whether various sections of the code are acting as expected under various circumstances. Test cases describe tests that need to be run on the program to verify that the program runs as expected.

Code driven test automation is a key feature of agile software development, where it is known as test-driven development (TDD). Unit tests are written to define the functionality before the code is written. Only when all tests pass is the code considered complete. Proponents argue that it produces software that is both more reliable and less costly than code that is tested by manual exploration. It is considered more reliable because the code coverage is better, and because it is run constantly during development rather than once at the end of a waterfall development cycle. The developer discovers defects immediately upon making a change, when it is least expensive to fix. Finally, code refactoring is safer; transforming the code into a simpler form with less code duplication, but equivalent behavior, is much less likely to introduce new defects.

Graphical User Interface (GUI) testing

Many test automation tools provide record and playback features that allow users to interactively record user actions and replay them back any number of times, comparing actual results to those expected. The advantage of this approach is that it requires little or no software development. This approach can be applied to any application that has a graphical user interface. However, reliance on these features poses major reliability and maintainability problems. Relabelling a button or moving it to another part of the window may require the test to be re-recorded. Record and playback also often adds irrelevant activities or incorrectly records some activities.

A variation on this type of tool is for testing of web sites. Here, the "interface" is the web page. This type of tool also requires little or no software development.[citation needed] However, such a framework utilizes entirely different techniques because it is reading HTML instead of observing window events.[citation needed]

Another variation is scriptless test automation that does not use record and playback, but instead builds a model of the Application Under Test (AUT) and then enables the tester to create test cases by simply editing in test parameters and conditions. This requires no scripting skills, but has all the power and flexibility of a scripted approach.[citation needed] Test-case maintenance seems to be easy, as there is no code to maintain and as the AUT changes the software objects can simply be re-learned or added. It can be applied to any GUI-based software application.[citation needed] The problem is the model of the AUT is actually implemented using test scripts, which have to be constantly maintained whenever there's change to the AUT.[citation needed]

What to test

Testing tools can help automate tasks such as product installation, test data creation, GUI interaction, problem detection (consider parsing or polling agents equipped with oracles), defect logging, etc., without necessarily automating tests in an end-to-end fashion.

One must keep satisfying popular requirements when thinking of test automation:

Framework approach in automation

A framework is an integrated system that sets the rules of Automation of a specific product. This system integrates the function libraries, test data sources, object details and various reusable modules. These components act as small building blocks which need to be assembled to represent a business process. The framework provides the basis of test automation and simplifies the automation effort.

Defining boundaries between automation framework and a testing tool

Tools are specifically designed to target some particular test environment. Such as: Windows automation tool, web automation tool etc. It serves as driving agent for an automation process. However, automation framework is not a tool to perform some specific task, but is an infrastructure that provides the solution where different tools can plug itself and do their job in a unified manner. Hence providing a common platform to the automation engineer doing their job.

There are various types of frameworks. They are categorized on the basis of the automation component they leverage. These are:

  1. Data-driven testing
  2. Modularity-driven testing
  3. Keyword-driven testing
  4. Hybrid testing
  5. Model-based testing

Notable test automation tools

Tool name Produced by Latest version
HP QuickTest Professional HP Software Division 11.0
HTTP Test Tool Open source 2.0.8
IBM Rational Functional Tester IBM Rational 8.2.2
LabVIEW National Instruments 2011
Maveryx Maveryx 1.2.0
Oracle Application Testing Suite Oracle Corporation 12.1
QF-Test Quality First Software GmbH 3.4.7
Ranorex Ranorex GmbH 3.2.3
Rational robot IBM Rational 2003
Selenium Open source 2.20
SilkTest Micro Focus 2011
eggPlant TestPlant 2012
EiffelStudio AutoTest Eiffel Software 7.1, Jun 2012
SOAtest Parasoft 9.2
TestComplete SmartBear Software 9.0
Testing Anywhere Automation Anywhere 7.5
TestPartner Micro Focus 6.3
TPT PikeTec GmbH 4.0
TOSCA Testsuite TRICENTIS Technology & Consulting 7.5.0
Visual Studio Test Professional Microsoft 2010
WATIR Open source 3.0
Telerik Test Studio Telerik, Inc. 2012.1

See also

References

This article includes a list of general references, but it lacks sufficient corresponding inline citations. Please help to improve this article by introducing more precise citations. (February 2009) (Learn how and when to remove this message)
  1. ^ Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 74. ISBN 0-470-04212-5. ((cite book)): More than one of |pages= and |page= specified (help); Unknown parameter |coauthors= ignored (|author= suggested) (help)
  2. ^ "Proceedings from the 5th International Conference on Software Testing and Validation (ICST). Software Competence Center Hagenberg. "Test Design: Lessons Learned and Practical Implications".
  3. ^ Brian Marick. "When Should a Test Be Automated?". StickyMinds.com. Retrieved 2009-08-20.