testing

You don't wait until the day before a software release to test the product. Testing software is a complex process, involving systematic investigation and sustained observation. In this week's column, James Bach argues that evaluating testers is similarly complex. And it shouldn't be put off until the night before the tester's performance review.

The goals of this presentation are to: Redefine the term "path"; Introduce four value selection paradigms; Discuss strengths & weaknesses of each; Examine how value selection relates to automated test design capability; and Examine how test requirements identification relates to each paradigm.

Examine the challenges and successes experienced by a test team analyzing application and systems performance for applications moving from distributed Client/Server solutions to centralized, Web-based designs. In this presentation, Nancy Landau presents case studies to address the changes made in automated testing methods to handle compressed delivery schedules, new architectures, new test tools requirements, and changing customer expectations. These case studies encompass principles such as managing iterative test development, creating reusable tests, standardizing application metrics, migrating from simple to complex networking environments, and predicting performance bottlenecks.

The four "lucky" organizational factors are: clearly defined roles within-and interfaces between-test team and project; early test team involvement in project; sharing of test cases, data, and tools across test participants and phases (levels); and a project culture that promotes understanding and valuing test team's contributions. How do these factors promote test success? How can we institute these auspicious circumstances on our projects?