|
|
Problems with Vendorscripts: Why You Should Avoid Proprietary Languages Most test tools come bundled with vendor-specific scripting languages that I call vendorscripts. They are hard to learn, weakly implemented, and most importantly, they discourage collaboration between testers and developers. Testers deserve full-featured, standardized languages for their test development. Here’s why.
|
Bret Pettichord, Pettichord Consulting
|
|
|
Teach Your Automation Tool To Be As Smart As You Teach your automation tool to speak your language instead of the other way around. This presentation demonstrates how test professionals can write automated scripts-without knowing coding-while providing a full complement of management reports that identify project progress, script status, and error tracking. You'll learn to fully integrate requirements, project management, and testing automation. Don't just use an automation tool, get it to do what you need it to do.
|
Bonnie Bayly, Anteon Corporation
|
|
|
Scripts on My Tool Belt The aims of this presentation are to: convince you that "test automation" is more than automating test execution; show some examples of the kinds of things that can be accomplished with scripting languages, using simplified code samples; and make you aware of three different scripting languages (shells, perl, and expect).
|
Danny Faught, Tejas Software Consulting
|
|
|
Results From Inspecting Test Automation Scripts In many ways, development of scripts for automated testing is similar to software development. It involves requirements, design, code, test, and use. So why not use proven improvement activities to enhance the test script development process? This presentation discusses how one software test team adjusted and applied inspections to test script development. Learn the results of these inspections and how you might use this technique to improve the test script development activity in your organization.
|
Howie Dow, Compaq Computer Corporation
|
|
|
Succeeding with Automation Tools The problems with using record/playback as your only test automation strategy are well known. But the other option-full script programming-is unattractive to many due to its high cost and long development time. This presentation discusses a strategy called defensive programming that incorporates the best of both worlds. Learn how to leverage your automation tool with simple implementation techniques to create robust test suites.
|
Jamie Mitchell, BenchmarkQA
|
