People often point to requirements documents and process manuals as ways to guide a new tester. Research into knowledge transfer, as described in The Social Life of Information, suggests that there is much more to the process of learning. Michael Bolton describes his own experiences on a new project, noting how the documentation helped ... and didn't.

Imprecise language makes understanding and, therefore, software verification more difficult. This article describes techniques for detecting and repairing vague and ambiguous software requirements.

In these times, many of us are being told to "do more with less." A more useful approach is "invest our organization's scarce resources where the return is the greatest." To do so, we must define the financial benefits sought when developing a system in addition to its requirements.

It's a technique children and teenagers have mastered: asking "why" until they get to an acceptable response (or until we're too tired to continue answering). Find out how Michele Sliger uses a similar approach designed by Six Sigma to drill down into the underlying cause of any problem within software projects. She then continues the inquisition with a series of other questions in order to find out how these problems affect business value and technology. Read on to learn what these questions are and how you can start using them to find out why things aren't going as planned.