TestArchitect

More documents

Recommendations

Info

FEATURE ARTICLEAn added feature allows actions to be sharedacross test projects by having a project“subscribe” to another “supplier” project. Thesubscriber can then use all actions of thesupplier project freely and any project thesupplier itself subscribes to are automaticallyavailable to the subscribing project.Subscriptions can be recursive and mutual: asupplier can subscribe to yet another project, inwhich case those actions are available for itssubscribers as well, and even a supplier projectcan subscribe to one or more of its ownsubscribers.The underlying concept in Action Based Testingis to design tests explicitly and to not rely onrecording of tests. However, for practicalreasons TestArchitect does come with arecording tool called the "Action Recorder."Instead of generating scripts this tool producesaction lines that can be inserted anywhere in atest module or action definition.Another important aspect of TestArchitect istest result management. After a test run, resultsare initially stored locally. The user must take anexplicit action to store them in the repositoryvisible to others and later have an impact onmetrics and reports. This process preventsrepositories cluttered with results of thenumerous ad hoc dry-runs users superviseduring testing or automation development.Once in the repository, results are furtherorganized with proper naming or storageplacement. Lastly, results are linked to the testmodules and test cases they have tested.Automation in TestArchitect is organized as aset of libraries that work completely separatefrom the test management and test designcomponents allowing you to program theactions in virtually any programming language.It is also possible to execute the tests in a thirdparty playback tool using its scripting languageto program the actions.All in all, TestArchitect is an ecosystem fortesters to design, automate, and manage testsgrounded in its core design of Action BasedTesting. Without this method, I believe it’s justanother playback similar to its counterparts. It’smy firm belief that TestArchitect serves toimprove the quality and implementation oftests. This to me is at the very core of ourprimary objectives as testers: to write great teststhat find meaningful bugs and help improveoverall application quality.www.logigearmagazine.com Page 5 of 14 January 2011 | Volume V
RELATED ARTICLESTest design focused on expeditingfunctional test automationBy David W. JohnsonTest organizations continue to undergo rapidtransformation as demands grow for testingefficiencies. Functional test automation is oftenseen as a way to increase the overallefficiency of functional and system tests. Howcan a test organization stage itself forfunctional test automation before aninvestment in test automation has even beenmade? Further, how can you continue toharvest the returns from your test designparadigm once the test automationinvestment has been made? In this article wewill discuss the factors in selecting a test designparadigm that expedites functional testautomation. We will recommend a test designparadigm and illustrate how this could beapplied to both commercial and open-sourceautomation solutions. Finally, we will discusshow to leverage the appropriate test designparadigm once automation has beenimplemented in both an agile (adaptive) andwaterfall (predictive) system developmentlifecycle (SDLC).Test design - selection criteriaThe test design selection criteria should begrounded in the fundamental goals of anyfunctional automation initiative. Let us assumethe selected test automaton tool will enableend-users to author, maintain and executeautomated test cases in a web-enabled,shareable environment. Furthermore, the testautomation tool shall support test case design,automation and execution "best practices" asdefined by the test organization. To harvest themaximum return from both test design and testautomation the test design paradigm mustsupport:Manual test case design, executionand reportingAutomated test case design, executionand reportingData-driven manual and automated testcasesReuse of test case "steps" or"components"Efficient maintenance of manual andautomated test casesTest design – recommended paradigmOne paradigm that has been gainingmomentum under several guises in the last fewyears is keyword-based test design. I havestated in previous articles that:"The keyword concept is founded on thepremise that the discrete functional businessevents that make up any application can bedescribed using a short text description(keyword) and associated parameter valuepairs (arguments). By designing keywords todescribe discrete functional business events thetesters begin to build up a common library ofkeywords that can be used to create keywordtest cases. This is really a process of creating alanguage (keywords) to describe a sequenceof events within the application (test case)."The Keyword concept is not a silver bullet but itdoes present a design medium that leads toboth effective test case design and ease ofautomation. Keywords present the opportunityto design test cases in a fashion that supportsour previous test design selection criteria. Itdoes not guarantee that these test cases willbe effective but it certainly presents thegreatest opportunity for success. Leveraging atest design paradigm that is modular andreusable paves the road for long termautomation – not only that, it moves most ofthe maintenance to a higher level ofabstraction: the keyword. The keyword nameshould be a shorthand description of whatactions the keyword performs. The keywordname should begin with the action beingwww.logigearmagazine.com Page 6 of 14 January 2011 | Volume V
Page 4 and 5: FEATURE ARTICLETestArchitect TMAUTO
Page 8 and 9: RELATED ARTICLESperformed followed
Page 10 and 11: RELATED ARTICLESknights experienced
Page 12: SPOTLIGHT INTERVIEWLogiGear: What a
Page 15: IN BRIEF…SUBMIT YOUR ARTICLE TO L

TestArchitect

Create successful ePaper yourself

Delete template?

Save as template?