The amount of time allocated to quality testing is always under pressure due to slippage in development and delivery dates-this often results in performance testing being overlooked in the quality process. This presentation examines various factors of performance testing including why it's important, how to determine the metrics that are essential to individual situations, and how to automate the collection and analysis of data. Ernest Huber gives you an example performance testing process, much of which is applicable to your quality assurance tasks.

Everyone knows that a large body of automated unit tests for classes, subsystems, and frameworks adds to overall code quality. However, the "burden" of unit test automation is frequently placed squarely on the shoulders of developers because of the perception that only a developer can write a unit test. Since QA personnel typically test from the user interface-and usually have to wait until later in the development cycle for the availability of that interface-they're often left to scramble at the end of the cycle to get their testing done. Michael Silverstein reveals a model for early-cycle collaboration between developers and testers where testers augment the developers' unit testing activities without adding additional process overhead.

Are you looking to apply the values of eXtreme Programming (XP) to test automation? In eXtreme Programming Explained, Kent Beck compares XP to driving a car-meaning the team must make constant corrections to stay on track. This includes plotting the course, establishing check points, tracking progress, and occasionally even asking for directions. But XP test professionals have a need for speed given their tight deadlines, so is this much process really possible? To be the windshield and not the bug, you have to use lightweight automated test frameworks and tools that won't slow you down. Lisa Crispin delivers pointers on selecting or developing these tools to assist in test automation.

More often than not, even modest software test automation efforts fail to achieve their goals. Usually these project shortcomings happen because the introduction of test automation reduces the effectiveness of the test group, thereby reducing the number of tests and the number and complexity of product defects found. Several common misconceptions about the value and techniques for software test automation contribute to this problem. Douglas Hoffman explores some of the more common issues and addresses how to recognize and avoid them. He delves into each blind alley, describing each one and showing you how and why they sometimes lead to failure. He then offers you strategies for understanding and avoiding them.