Test-Driven Design for the Project Manager


The Fit of TDD
TDD was “invented” to serve a purpose. Martin Fowler, a respected thought leader in the agile space, opines: “TDD's origins were a desire to get strong automatic regression testing that supported evolutionary design.”[2]

TDD is more or less at the bottom of the testing hierarchy. Next up: unit tests. Unit tests, as distinct from TDD tests, are post-implementation design verification tests. In most respects, unit tests and TDD tests are very similar, but the purposes are very different: The latter drives design and the former is to verify implementation.

Unit tests feed into multiple object integration tests, system performance tests, functional tests, and perhaps others unique to the deliverables. All this fits into a pyramid we call the Test-driven Project Pyramid.

Project-level TDD
TDD in its customary description is a low-level design practice combined with a design test. But, project managers of necessity have a more strategic outlook. Consider the idea illustrated in figure 2.

Figure 2: Test-driven Project Pyramid

Notional concept: A notion in a conception which expresses the main ideas of the business sponsor but is bereft of many details like inclusions, exceptions, regulations, and implementation details of feasibility and support.

Every project begins with some notional idea—to wit, the problems to be solved or concepts to be implemented. For business reality, it’s also necessary to conceptualize what the metric evidence of success will be.

Notion synthesis is always an exercise in problem categorization, inter- and intra-problem relationships, and priorities. But, in design terms, notions are not actionable; thus, there follows a flow-down through the Test-driven Project Pyramid.

Business narrative: A narrative is a plain-language description of business operations. In other words, the narrative answers this question: What's the business operational context and working protocol for the notional concept? Within the pyramid, the narrative is the genesis of use cases.

Business rules provide operational governance for the narrative. Rules aren't processes, but processes enforce rules, whether the rules are implemented as workflow and function/feature controls or implemented administratively by the business.

Scripted cases: A scripted case is a test script form of the use case narratives derived from the business narrative. The scripted case primarily drives functional testing, but also drives performance testing if the test environment is a true operational setting.

Conditioned scenario: This is a scripted case with specific business conditions imposed for testing. An “instance” is a specific test execution of the conditioned scenario. An instance passes or fails.

Unit scripts: These are scripted tests that verify object function and performance to include integrated systems of objects.

TDD scripts: These are scripts that document the lowest level of user requirements.

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!