The Role of the Analyst in Testing 

Richard Bender, Bender RBT, Inc.

Although many organizations ask their analysts to do double-duty as testers, this presents a number of challenges. Because the majority of defects have their basis in requirements errors and omissions, the authors of those requirements—the analysts—should not be the ones to design tests of their own work. However, Dick Bender believes there is a significant role that analysts, partnering with testers, can play in your projects. Using examples from a variety of industries, Dick describes how analysts can use their skills and domain knowledge to provide unique insights into the system within the testing effort. Learn how analysts and testers can partner to focus on requirements validation early in the project to move many user acceptance testing activities earlier in the project—before coding starts. Discover ways analysts can participate later in the project to assess the completeness and usability of the system under test.

Automating Web Testing with cURL and Perl

Paco Hope , Cigital

With little or no budget to acquire test automation tools for Web applications, many testers think there is nothing they can do to replace manual tests with automated ones. Not true! Paco Hope introduces two free tools—cURL and Perl—and explains how you can use them to design both positive (functional) and negative (security) test cases. cURL is a free program that helps automate HTTP, HTTPS, and other common types of Web commands. Perl is a well-known programming language well-suited for writing test scripts. Paco describes the basics of automating tests with these tools and explores the automation complexity that these tools help solve. He demonstrates how a few simple commands can generate thousands of test cases, whether your Web platform is Java EE, .NET, or something else. Leave with an understanding of scripting basics and a list of resources you can turn to for learning more about free Web test automation tools.

Today, a large portion of computing is moving off the desktop, out of the organization, and into the cloud. Services such as SalesForce.com, Microsoft’s Online Businesses, and Oracle’s On Demand provide both IT and line-of-business application support outside the corporate IT infrastructure. Amazon.com’s S3 service and Microsoft’s Azure platform provide cloud infrastructures while Google Apps and Star Office are attempting to supplant the classic desktop applications. With this technology shift, the techniques, tools, and even the role of testing are rapidly evolving.  Ken Johnston describes the keys to testing success with software and systems that have migrated to the cloud. Ken describes efficient ways to test service infrastructures, the intersection of test automation with monitoring, and the challenges of testing while systems are in production. Hear practical examples of challenges Microsoft and its partners are dealing with to improve product quality while simultaneously changing the paradigms for software delivery.

Many teams test software on a wide variety of operating system and hardware environment configurations. Traditionally, they use dozens—sometimes hundreds—of machines in their offices and test labs to get the job done. The cost of maintenance of the machines, electrical costs (including power and cooling), and the physical space occupied by the machines all contribute to a budget that can quickly head into the stratosphere. Alan Page describes how leveraging multiple virtual machines on a single host machine will mitigate these budget issues. He shares case studies that show how teams at Microsoft use virtualization to reduce maintenance costs, electrical costs, and machine usage. Alan describes other distinct advantages of virtualization they have discovered, including automatic setup of network topologies. Take back proven tips on when virtualization can benefit you—and, as importantly, when it won’t help at all.

Once upon a time, in testing conferences not so long ago, Rob Sabourin presented useful testing lessons from the most unlikely sources: the Looney Tunes gang, the Great Detectives, Dr. Seuss, Hollywood movies, the game of baseball, Monty Python, labor and delivery nursing, and the Simpsons. Now he turns his attention to lessons from classic fairy tales, those timeless fables designed to entertain and teach simple moral truths to children that also have important lessons for testers. What can the Three Pigs teach us about contingency planning? Can Mother Goose teach us to be great test leads? Can testers get the message across without crying wolf and live to tell the tale? What does Red Riding Hood teach us about critical thinking? Can we learn fundamental test design approaches from Goldilocks and the Three Bears? Were Hansel and Gretle test driven developers? Rob takes us through the realm of fairy tales, discovering wonderful, practical, and simple testing lessons that you can apply right away.

Test automation efforts frequently fail because of unrealistic expectations, often the result of choosing poor objectives for automation. Dorothy Graham explains the pitfalls of a number of commonly-held objectives for automation and describes characteristics of good automation objectives. These objectives seem sensible at first and are common in organizations – find more bugs, run regression tests overnight and weekends, reduce testing staff, reduce elapsed time for testing, and automate x% of the testing. Finding more bugs is a good objective for testing, but not for automation, especially automation of regression tests. Running tests outside working hours is only worth doing if the tests are worth running. Reducing testing staff is a management issue, not an automation objective – in the majority of cases, more staff is needed, not less! Reducing elapsed time for testing is meaningless as running automated tests is only a small part of testing. Manual and automated tests should not be the same and some manual tests are not worth automating.

Web services interoperability testing is complex, subjective, and unlike traditional testing in many ways. The Web Services Interoperability (WS-I) organization provides a wealth of materials and tools about interoperability. With this help, his organization increased the confidence in the interoperability of their Web services—beyond the scope of vendors' testing tools. Christopher describes the WS-I test information that helped justify additional interoperability testing. In addition, WS-I testing tools helped him determine when their Web services "colored outside the lines" by going beyond what the Web services community has agreed upon as the foundations for interoperability. Learn to assess your specific implementation against the WS-I Profiles requirements while determining if your application’s Web services extensibility points could adversely affect interoperability. Go beyond the test designs of traditional applications to help assure that your Web services operate as advertised—the first time and every time.

Workflow-based Web application security defects are especially difficult on enterprises because they evade traditional simple point-and-scan vulnerability detection techniques. Understanding these defects, and how and why black-box scanners typically miss them, is the key to creating a testing strategy for successful detection and mitigation.  Rafal Los describes the critical role that application testers play in assessing application workflows and how business process-based testing techniques uncover these flaws. Rafal demystifies the two main types of workflow-based application vulnerabilities: business process/logic vulnerabilities and parameter-based vulnerabilities. As the complexity of Web applications continues to increase, learn how to adjust your testing strategy to make sure you don’t miss these unique types of defects.