Editing Test automation (section)

==Considerations==
===Factors to consider for the decision to implement test automation ===
What to automate, when to automate, or even whether one really needs automation are crucial decisions which the testing (or development) team must make.<ref>
{{cite web|url=http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=ART&ObjectId=2010|title=When Should a Test Be Automated?|author=Brian Marick|publisher=StickyMinds.com|access-date=2009-08-20}}</ref> A multi-vocal literature review of 52 practitioner and 26 academic sources found that five main factors to consider in test automation decision are: 1) System Under Test (SUT), 2) the types and numbers of tests, 3) test-tool, 4) human and organizational topics, and 5) cross-cutting factors. The most frequent individual factors identified in the study were: need for regression testing, economic factors, and maturity of SUT.<ref>{{Cite journal|last1=Garousi|first1=Vahid|last2=Mäntylä|first2=Mika V.|date=2016-08-01|title=When and what to automate in software testing? A multi-vocal literature review|journal=Information and Software Technology|volume=76|pages=92–117|doi=10.1016/j.infsof.2016.04.015}}</ref>

===Plateau effect===
While the reusability of automated tests is valued by software development companies, this property can also be viewed as a disadvantage. It leads to the so-called [[Plateau effect|"Pesticide Paradox"]], where repeatedly executed scripts stop detecting errors that go beyond their frameworks. In such cases, [[manual testing]] may be a better investment. This ambiguity once again leads to the conclusion that the decision on test automation should be made individually, keeping in mind project requirements and peculiarities.

===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 [[test oracle]]s), defect logging, etc., without necessarily automating tests in an end-to-end fashion.

One must keep satisfying popular requirements when thinking of test automation:
* [[Computing platform|Platform]] and [[Operating system|OS]] independence
* Data driven capability (Input Data, Output Data, [[Metadata]])
* Customization Reporting (DB [[Data Base]] Access, [[Crystal Reports]])
* Easy debugging and logging
* [[Version control]] friendly – minimal binary files
* Extensible & Customization (Open [[API]]s to be able to integrate with other tools)
* Common Driver (For example, in the Java development ecosystem, that means [[Apache Ant|Ant]] or [[Apache Maven|Maven]] and the popular [[Integrated Development Environment|IDEs]]). This enables tests to integrate with the developers' [[workflows]].
* Support unattended test runs for integration with build processes and batch runs. [[Continuous integration]] servers require this.
* Email Notifications like [[bounce message]]s
* Support distributed execution environment (distributed [[Testbed|test bed]])
* Distributed application support (distributed [[System Under Test|SUT]])