Many testing organizations focus primarily on software executable code, but that's not the only thing you can test. For instance, did you ever consider testing your software requirements? When you test only code, you face some big disadvantages, not to mention that design defects often aren't even fixable because they demand too much effort, too late in the release cycle. In fact, it's difficult to even report some requirements defects since the developers have already committed to the design strategy. But if you test your requirements early in the game, you can discover defects before they're cast into designs and code, consequently saving your organization potentially huge rework costs.

"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.

Are you looking for a way to effectively set the expectations of senior management? The Functional Readiness Matrix (FRM) is a decision-making tool that offers a simple way to represent test progress based on the functional areas or features of an application. By enabling the test team to track actual test progress against the implementation goals established early on, the FRM allows for the presentation of valid test metrics to management in a way they can understand.

Users find 25 percent of your defects after your software goes live, according to a recent study. In addition to being expensive to fix, these post-ship defects often prove impossible to find due to the many potential user environments out there. Flight recorders are new tools, named after those already present on aircraft, that trace the execution of an application in or before production. Their job is to collect information while the system runs. Then, if a problem or failure occurs, you can examine the trace file and discover what operations led to the problem without actually having to recreate the problem.