Application Lifecycle Management

Today's large-scale enterprise applications are all Web-enabled and complex in nature. Many users experience performance problems from day one. Performance evaluation and measurement via extensive testing is the only practical way to raise and address all issues prior to a successful deployment. Learn how to tackle performance and capacity issues with the appropriate testing strategy and scalable infrastructure/architecture.

Adaptive Software Development (ASD) is targeted for software teams where competition creates extreme pressure on the delivery process. Many process improvement techniques (CMM, ISO) are focused on optimizing practices that involve steadily increasing rigor. In contrast, ASD emphasizes producing high-value results based on rapid adaptation to both external and internal events. Listen as Jim Highsmith explains how the focal point of ASD is fundamentally different from traditional software process improvement approaches. Learn why "a little bit less than just enough" is ASD's guideline for implementing rigor.

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.

In testing utopia, all software products submitted for testing have thorough and comprehensive documentation describing how every program function should work. On planet Earth, however, test engineers usually have to make do under less-than-ideal circumstances. It's not uncommon for test engineers to be asked to verify the functionality of a critical legacy system which has no documented requirements whatsoever. While there are many reasons this can happen, the result is the same: You assume the role of an archeologist sifting through the layers of clues to reconstruct the specifications. Patricia Ensworth gives you instructions and tools so you'll be ready to roll up your sleeves and dig.