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.

Testware: the stuff of which tests are made. The term comprises a bewildering range of artifacts including data files, scripts, expected results, specifications, and environment information. It also implies how these artifacts are arranged, where they're stored and used, and how they're grouped and referenced. Since testware architecture has not traditionally been considered an important issue, individual projects and teams, even individual testers, have evolved their own approaches to the arrangement of their testware, resulting in much wasted effort. Of course, different applications and environments may demand unique testware architectures, but do they have to be so different? Isn't there a single, unified, flexible, and expandable approach that fits most, if not all, situations within an enterprise? Perhaps not, but the goal of uniform testware architecture across projects is certainly worth striving for.

When processes include several applications, the testing process is complicated in many ways. Possible complications include: organizational issues because of the multitude of test teams and their interdependencies; processes and transactions that span the chain which require new test scenarios; integral design, information analysis, and process design documents that aren't fit for the purpose of chain testing; and test execution that demands integral knowledge of the chain. This session gives you a list of all the variables that need to be considered, then offers solutions for successfully organizing chain testing.

"This isn't what I need," states Customer Bob. "But it's what you said you wanted," replies Engineer Joe. "It's not right. I need something else." We've all encountered this classic users-don't-know-what-they-want scenario. The fact that software professionals continue to have this same experience over and over again suggests that we're overlooking the real reasons for the user/engineer disconnect. This presentation contrasts the different uses of the term "requirements" as it explores the possible solutions to improving understanding between business people and technical people.