Test automation management tools: Difference between revisions

Revision as of 16:14, 7 January 2022

Latest revision as of 23:45, 4 May 2025

(6 intermediate revisions by 6 users not shown)

Line 5:

==Motivation==

[[Test automation]] systems usually lackneed more reporting, analysis and meaningful information about project status. Test management systems target manual effort and do not give all the required information.<ref>{{cite book | last = Kartashov | first = Peter| title = Test Automation Management: A Call For Better Tools | url = http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&id=1276:ast-magazine&catid=105:ast-cover-description&Itemid=122 | archive-url = https://web.archive.org/web/20100615024956/http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&id=1276:ast-magazine&catid=105:ast-cover-description&Itemid=122 | url-status = usurped | archive-date = June 15, 2010 | year = 2011| publisher = Automated Software Testing Magazine}}</ref>

Test automation management systems leverage automation effortefforts towards efficient and continuous processes of delivering test execution and new working tests by:

* Making transparent, meaningful and traceable reporting for all project stakeholders.

* Easing test debugging through test results analysis workflow.

Line 17:

==Compliance with Agile==

Test automation management tools fit [[Agile software development|Agile]] Systems Development Life Cycle methodologies. In most cases, test automation covers continuous changes in order to minimize manual regression testing. Changes are usually noted by monitoring test log diffs. For example, differences in the number of failures signal probable changes either in AUT or in test code (broken test code base, instabilities) or in both. Quick notice of changes and unified workflow of results analysis reduces testing costs and increases project quality.

== TDD ==

Line 23:

== Continuous Integration ==

Another test automation practice<ref>{{cite book | last = Kolawa | first = Adam |author2=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 = 978-0-470-04212-50 }}</ref> is [[continuous integration]], which explicitly supposes automated test suites as a final stage upon building, deployment and distributing new versions of software. Based on acceptance of test results, a build is declared either as qualified for further testing or rejected.<ref name="Fowler, Continuous Integration practices" >{{Cite web

|url=http://martinfowler.com/articles/continuousIntegration.html#PracticesOfContinuousIntegration

|title=Continuous Integration

|accessdate=2009-11-11

|last=Fowler |first=Martin |authorlink=Martin Fowler (software engineer)

}}</ref> Dashboards provide relevant information on all stages of software development including test results. However, dashboards do not support comprehensive operations and views for an automation engineer. This is another reason for dedicated management tools that can supply high-level data to other project management tools such as [[test management]], [[issue management]] and [[Change management (engineering)|change management]].

==References==

Line 35:

{{DEFAULTSORT:Test Automation Management Tools}}

[[Category:Automation software]]

[[Category:Software testing tools]]

[[Category:Collaborative software]]