Content deleted Content added
No edit summary |
No edit summary |
||
Line 3:
==Motivation==
[[Test automation]] usually lacks of reporting, analysis and providing meaningful information about project status from automation perspective<ref name=AT4QA>{{cite web|last=Peter|first=Kartashov|url=http://at4qa.blogspot.com/2009/12/make-your-contribution-visible-or-die.html|work=QA|publisher=Peter Kartashov|title=Make your contribution visible or die}}</ref>. Test management systems from the other hand mostly targeted on manual effort and cannot give all the required information.
Test automation management system leverages automation effort towards efficient and continuous process of delivering test execution and new working tests by:
* Making transparent, meaningful and traceable reporting for all project stakeholders
Line 20:
== Continuous Integration ==
Another proper test automation practice <ref>{{cite book | last = Kolawa | first = Adam | coauthors = Huizinga, Dorota | title = Automated Defect Prevention: Best Practices in Software Management | url = http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html | year = 2007 | publisher = Wiley-IEEE Computer Society Press | isbn = 0470042125 }}</ref> is being part of [[Continuous integration|continuous integration]] which explicitly supposes to have automated test suites as final stage upon building, deployment and distributing new version of software. Basically, based on acceptance test results, a build is declared either as qualified for further testing or not qualified (rejected).<ref name="Fowler, Continuous Integration practices" >{{Cite web
|url=http://martinfowler.com/articles/continuousIntegration.html#PracticesOfContinuousIntegration
|title=Continuous Integration
Line 35:
* [[Test management|Test management tools]]
* [http://gredy.net Gredy - the only test automation management tool]
[[Category:Automation]]
[[Category:Software_testing]]
[[Category:Collaborative_software]]
[[Category:Test_management_tools]]
| |||