Test-Driven Design for the Project Manager

[article]
Summary:
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.

 All truths are easy to understand once they are discovered; the point is to discover them. -Galileo

Test-driven design (TDD) is a well-known developer’s practice in the software development industry, and it’s a practice favored by many as the best starting point for design after a developer has dissected a user story with the counsel of a functional user. So, although the label “test-driven” would lead you to believe that TDD is first a test method, in fact it is first a design method and only then a test method.

A Manager’s View of TDD
The general proposition is straightforward:

  • Document a design requirement in the form of a test script, thereby accomplishing two tasks in one stroke.
  • Then, run a test according to the script with the expectation of a failure—after all, nothing’s been designed and implemented. Of course, if the test doesn’t fail, then that means the product base already supports the requirement and nothing more’s to be done.
  • If the test fails, then design and implement an object that will pass the test—in effect, design to pass. If the test passes, clean up the coding and documentation if needed, and update the product base with the new object.

This three-step cycle is commonly known as red-green-refactor after the idea that first the test fails (red), then the test passes (green), and finally the coding is upgraded to meet the project’s coding standards (refactor).

Some advantages to the TDD cycle are self-evident:

  • Self-verification: The functional user story, the TDD test that proves the object faithfully implements the story, and the TDD design description or specification of the object are tightly coupled, and they are self-verifying—to change one requires validation with all.
  • Lead to higher-level tests: The lead-in to unit testing and ultimately integration testing is a smooth arc from sponsor’s vision to user story via design, implementation, and integration.
  • User in the loop: There is a virtuous circle, as illustrated in figure 1, which opens and closes on the user who stands in for all the beneficiaries of the project. The user validates the use case, validates the derived user stories, approves—for functional compliance, at least—the test script that is also the documentation of the design requirement, and then validates the integrated deliverables.


Figure 1: Virtuous Circle of TDD

Guidance Principles
Every testing doctrine like TDD is framed by a set of guidance principles set forth by the project manager and endorsed by the project team, as given by the examples in table 1.

Pages

About the author

John C. Goodpasture's picture John C. Goodpasture

John C. Goodpasture, PMP and managing principal at Square Peg Consulting, is a program manager, coach, author, and project consultant specializing in technology projects, strategic planning, and risk management. He has had senior management assignments responsible for technology R&D, business operations, and web commerce. John is the author of Project Management the Agile Way: Making It Work in the Enterprise. He blogs at johngoodpasture.com, and his work products are found in the library at www.sqpegconsulting.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03