eXtreme programming emphasizes test-first coding-you write the tests before writing the implementation code. You can apply the same approach in design when developing a complex system, including an architecture to support testing. To be successful, systems developed with agile methods must support a high level of testability and test automation. For large distributed systems, more sophisticated testing is needed to help determine which components may be contributing to failures. For such complex systems, you should architect the system for testing rather than add testing functionality as an afterthought. Ken Pugh presents a framework that employs polymorphic-style internal and external interface patterns to ease the work of testing and debugging. He also covers adding test-only functionality, test-only outputs, and test-only logging to interfaces.
Usability testing of early GUI designs with paper prototypes validates that you are building the right applications for your customers. This low-cost, high-impact practice allows you to rapidly evolve the GUI interface and find many design bugs early in the development process before coding begins. With this process, you can get external customers and internal users actively involved in designing and testing the GUI with tools they can easily manipulate. Based on project experiences at The MathWorks, Inc., you will learn how to move from the paper prototype to a coded GUI and a set of automated tests. In addition, you will learn to develop user documentation while working back and forth between the GUI and the test plan to clarify design choices.
Involving everyone in GUI design early in the project
User tasks and scenarios as the basis for GUI validation
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
Tanya Martin-McClellan, Texas Mutual Insurance Company
Expressing requirements as user stories is one of the most broadly applicable techniques introduced by eXtreme Programming and adopted by other agile development processes. User stories are an effective approach for capturing requirements from an agile project, not just those using XP. In this session learn what user stories are, how they differ from other requirements approaches, and why you should consider using them. You also will learn the six attributes all good stories must exhibit and see how to get started with user stories. Whether you are a developer, requirements analyst, tester, manager, or even a customer interested in applying agile techniques to your projects, this session is for you.
The differences between user stories and other requirements documentation
Attributes of "good" user stories
Examples of User Stories from agile development projects
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 patterns are powerful tools when understood and employed properly. Combining design patterns and test-driven development (TDD) using a set of design principles will achieve higher productivity and quality than either practice alone. With numerous code snippets as examples, Thirumalesh Bhat describes the design principles and resulting patterns that have been extracted from TDD practices at Microsoft. Learn more about these design principles: commonality/variability analysis, open/closed principle, high cohesion, low coupling, prototyping, designing for current features, single point of maintenance, refactoring, unit testing, testability, and cost/benefit analysis. Adapt and apply these principles and design patterns to your TDD projects for the same benefits.
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.
Use cases are a wonderfully simple concept: document a system's functional requirements by writing down scenarios about how using it delivers value to its actors. However, writing effective use cases is more difficult than expected because you frequently must deal with difficult questions, such as: scope, level of detail needed for different people and projects, how to describe external interfaces, stored data, and more. You need a source of objective criteria to judge use case quality and effectiveness. Fill this critical information gap with a pattern language that provides simple, elegant, and proven solutions to common problems in use case development. Take away these use case patterns and profit from the knowledge and experience of other successful use case writers. And develop a new vocabulary for describing the properties of quality use cases.
The "signs of quality" and properties of a good use case
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
Using a challenging client engagement as a case study, Rex Black shows you how he and a team of test engineers created an integrated, automated unit, component, and integration testing harness, and a lightweight process for using it. The test harness supported both static and dynamic testing of a product that ran on multiple platforms. The test process allowed system development teams spread across three continents to test their own units before checking them into the code repository, while the capture of the tests provided automated integration testing and component regression going forward. He'll also explain the tools available to build such a testing harness and why his team chose the ones they did.
Examine the benefits-and challenges-of implementing an integrated, automated component and integration testing process in a Java/EJB development environment