Test-Driven Design for the Project Manager

Many developers and testers are familiar with test-driven design (TDD), but how can managers use it to drive project implementation? In this article, John Goodpasture offers a guide to TDD design from the project manager’s perspective.

John C. Goodpasture's picture John C. Goodpasture
Heuristics for Rapid Test Management

Whether you are a tester or a test manager, Jon Bach believes you have little time to do the things you want to do. Even the things on your "absolutely must do" list are competing for your limited time. Jon has a list of what he calls "half-baked" ideas on how to cope. That is, these ideas are still in the oven-still being tested. In his role as a tester and manager, Jon has learned that it's not about time management; it's really about energy management-where you focus your personal energy and direct your team’s energy. Jon shares ideas that have worked for him and some that have failed: Open-Book Testing, Dawn Patrols, Tester Show-and-Tell, Test Team Feud, and Color-Aided Design. Learn how these ideas may solve your problems with test execution, reporting, measurement, and management-all at low or no cost and relatively easy to implement.

Jon Bach, Quardev, Inc.
Patterns of Testability

Testability requires interfaces for observing and controlling software, either built into the software itself or provided by the software ecosystem. Observability exposes the input and output data of components, as well as monitoring execution flow. Controllability provides the ability to change data and drive actions through the component interface. Without testability interfaces, defects are harder to find, reproduce, and fix. Manual testing can be improved by access to information these interfaces provide, while all automated testing requires them. Alan Myrvold shares software component diagrams that show patterns of testability. These patterns will help you architect and evaluate the observability and controllability of your system. Apply these testability patterns to describe and document your own testability interfaces.

Alan Myrvold, Microsoft
Mocks and Making Tests Easier to Read

There has been a lot of recent discussion on Twitter about the use of mocking frameworks and writing readable tests. Here is a roundup of some of the recent blogs on the subject.

Making Tests More Readable

Daniel Wellman's picture Daniel Wellman
Learning from Reading (and Rewriting) the Tests

Automated unit tests verify that a component is working as expected.  They also serve as a way to understand how code works, though this doesn't always happen by reading tests.  Sometimes understanding comes from tweaking the tests to observe new failures, or rewriting the tests themselves. 

Daniel Wellman's picture Daniel Wellman
Architecture and Design: What Managers Need to Know

In many current software development approaches, architecture and design are downplayed. Rather than actually architecting products, good designs are assumed to "emerge." Yet, managers must be confident that their products are well designed. In their efforts to produce products quickly, teams may overlook vital architecture and design issues, such as performance, security, usability, and accessibility. When managers try to help, they can be deterred by jargon and tools that are difficult for non-programmers to understand. Jonathan Kohl illustrates a way for managers to understand and influence product architecture and design. You don't need detailed technical skills to provide valuable insight into a project. Learn how to understand an application and its impact in three contexts: the code (where the application is developed), the system (where the application operates), and the social context (where the application is used).

Jonathan Kohl, Kohl Concepts Inc.
Ensuring Quality Requirements

Quality assurance is more than just testing software through processing a series of controlled inputs and outputs. It must also include an assessment of all the deliverables associated with the project. Developers and testers often view software documentation as merely a source of information, not as artifacts that require evaluation. All software documentation should undergo a rigorous quality assessment just as the actual software is subject to comprehensive testing. Mark Haynes describes quality models and attributes that can be used to evaluate requirements documents. He shows how imprecision (that will haunt you later) can be detected and removed through a set of formal criteria and informal heuristics. To experience using these techniques, Mark shares examples of poorly written requirements for you to evaluate and improve. Additional quality attributes, even subjective ones, can be used to conduct a quality dialogue.

Donald Haynes, Synova
Feature Injection: Part One

We are leaving the "last responsible moment" for a while. This month we start a discussion of Feature Injection, an analysis process based on real options and Kolb's circle of learning. The first episode ( of five ) introduces the "Information Arrival Processes.

StickyMinds Editorial's picture StickyMinds Editorial
Refactoring Doesn’t Mean Rewrite

Peter Schuh writes that it is not a good thing that the use of the term refactoring has grown so common, which makes him cringe every time he hears a business person say the word. Refactoring is meant to be one skill of many that is second-nature to a journeyman programmer.

Peter Schuh
Agile Engineering for Architects

Agile development requires architects and architecture, but the current user story-centric approach ignores the qualities of systems, instead overly focusing on features and functions. Sadly, developers who depend primarily on stories miss enormous value-creation opportunities for stakeholders. Developers often think system qualities (non-functional requirements) are someone else's responsibility to define. Even when defined, these qualities are typically not quantified, instead specified with vague terms such as "faster" and "better". Ryan Shriver believes that architects are needed to build successful systems. Architects think like engineers and actively participate in quantifying the key system qualities and then designing to implement those qualities. Ryan demonstrates techniques architects can use that are lightweight-but-rigorous and can be applied to agile projects of any size.

Ryan Shriver, Dominion Digital


StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.