Test automation management tools: Difference between revisions

Content deleted Content added
copyediting
Tag: gettingstarted edit
GreenC bot (talk | contribs)
Rescued 1 archive link; reformat 1 link. Wayback Medic 2.5 per WP:USURPURL and JUDI batch #27aj
(20 intermediate revisions by 17 users not shown)
Line 1:
{{Short description|Tools for managing test automation}}
{{copyedit|date=March 2013}}
{{refimprove|date=February 2011}}
{{Software development process}}
'''Test automation management tools''' are specific tools that provide a [[Collaborative software|collaborative]] environment that is intended to make [[test automation]] efficient, traceable and clear for stakeholders. Test automation is becoming a cross-discipline (i.e. a mix of both testing and development practices,) therefore, the need for a specific and dedicated test automation environment is becoming vital.)
 
==Motivation==
[[Test automation]] systems usually lacksneed more reporting, analysis and meaningful information about a project's status. Test management systems target manual effort and doesdo 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 systemsystems leveragesleverage 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 built-in test results analysis workflow.
* Providing valuable metrics and KPIskey performance indicators – both technical and business-wise (trend analysis, benchmarking, gap analysis, [[root cause analysis]], and risk point analysis).
* Grid benchmarking and comparison of test execution days reduces analysis and review effort.
* Clean traceability with other testing artifacts (test cases, data, issues, etc.).
* KeepingOrganizing historical data in a single place.
* Post -project analysis and automation performance assessment. (Progress of test coverage shows the group performance.)
 
==Compliance with Agile==
Test automation management tools are perfectly fit [[Agile software development|Agile]] methodologiesSystems andDevelopment SDLCLife Cycle methodologies. In most cases, test automation covers continuous changes in order to minimize manual regression testing, therefore, at glance reporting is essential in order to be up to date and move the project quickly. The changesChanges are usually noted by seeing differences of errors inmonitoring test logslog between day A and day A+1diffs. For example, differencedifferences in the number of failures (logs errors) signal about probable changes either in AUT or in test code (broken test code base, instabilities) or rarely in both. Quick notice of changes and unified workflow of results analysis ultimately reduces cost of testing overallcosts and increases project quality attributes.
 
== TDD ==
Line 21 ⟶ 23:
 
== Continuous Integration ==
Another proper test automation practice <ref>{{cite book | last = Kolawa | first = Adam | coauthors 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 being part of [[continuous integration]], which explicitly supposes to have 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 not qualified (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> CI web dashboardsDashboards provide relevant information on all stages of software buildingdevelopment including automation test results. However, CI dashboards do not support comprehensive operations and views for an automation engineer. This is another reason for having dedicated management tools whichthat can supply high-level data to other project management tools such as CI, [[test management tools]], [[issue management]], and [[Change management (engineering)|change management]].
 
==References==
{{Reflist}}
 
==See also==
* [[Test management]]
* [[Test automation]]
* [[Test management|Test management tools]]
 
{{DEFAULTSORT:Test Automation Management Tools}}
[[Category:Automation software]]
[[Category:Software testing tools]]
[[Category:Collaborative software]]