Requirements are supposed to be the basis of most test cases, but can you use test cases to define what the system needs to do--to improve or to actually become the requirements? To some degree, your development process dictates the opportunities you have for test cases to define or refine requirements. However, everyone can benefit from test case writing techniques to identify missing requirements, surface ambiguous statements, and expose implied requirements early in the process. Find out how Tanya Martin-McClellan produces test cases that accurately reflect the requirements, as they are understood at the time, and conducts team reviews to find the gaps and misunderstandings. Although more time is spent writing and rewriting test cases, less time is spent later discussing requirements.

• Find the vaguely defined parts of the requirement definition
• A template of implied requirements you can customize

The period 2002-2004 was one of enormous progress in figuring out how testing fits in on agile projects. Test-driven design is more about designing and writing the code than about finding bugs. New testing tools such as xUnit and FIT came out and received a lot of use by early adopters. The hopeful notion that customers would write acceptance tests to find bugs was expanded, challenged, and deepened. With all that progress, it's hard to be dissatisfied with these methods in agile projects. But past ways of thinking are holding us back. To make further progress, we have to split our notion of testing into two parts: the task of after-the-fact product critique, and a role that has nothing at all to do with bugs and, really, little to do with the word "testing." Brian Marick, a founding member of the Agile Alliance, explains what that role presents and some ideas on how to fill it.

Design and architecture decisions made early in the project have a profound influence on the testability of an application. Although testing is a necessary and integral part of application development, architecture and design considerations rarely include the impacts of development design decisions on testability. In addition, build vs. buy, third party controls, open source vs. proprietary, and other similar questions can affect greatly the ability of an organization to carry out automated functional and performance testing-both positively and negatively. If the software or service is delivered to a separate set of end-users who then need to perform testing activities, the problems compound. Join Jay Weiser to find out about the important design and architecture decisions that will ensure more efficient and effective testability of your applications.

In the Earned Value Management (EVM) approach, as work is performed, it is "earned" on the same basis it was planned-both the original plan and agreed to changes. Today, more and more software projects are using this approach. Function Point Analysis has been shown to be a reliable method for measuring the size of computer software based on detailed requirements and specifications. Function points can be leveraged throughout the EVM process to establish cost and schedule baselines, control project scope over the lifecycle, and quantitatively assess percent complete. Ian Brown delves into the concepts of EVM as applied to software development and the key conditions necessary to profitably employ this management technology. Learn how companies are using function point analysis to improve the technology.

• Earned Value Management applied to software development projects