4squareviews

In the second chapter of his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, John Stenbeck introduces agile project management, including the different frameworks that exist in the agile world and some tools which can be used independently in conjunction with any of these frameworks.    The first example of an agile project management tool is Test Driven Development (TDD).

Although it can be used in conjunction with other agile frameworks, it originally grew out of concepts from the Extreme Programming (XP) framework (for more information, see my post outlining XP).   Its most common usages are

• automating an existing manual process that has a current testing process
• improving legacy code developed with older languages

TDD uses repetition of very short development cycles.   Here are the steps in each cycle:

1. Developer writes test preconditions, test controls, and test reporting based on predicted outcomes that define a desired improvement or new function.
2. Developer then writes code and uses automated testing software tools to monitor the execution of the code to test the actual outcomes against the predicted outcomes mentioned in step 1.
3. If as a result of step 2, the code fails the automated test case, the developer refines it until code is produced that passes.   Only then does the developer go on to step 4.
4. The developer refactors the code, processing the code with a tool that makes small changes that do not modify its functionality, but improve attributes like a) readability, b) complexity, c) maintainability, and d) compliance with architecture or object model standards for extensibility until the new code meets established standards.

The focus in TDD for the programmer is on passing the immediate test and only then considering how to handle exceptions, errors, and rare circumstances.    However, TDD not only provides validation of the correctness of code, but it can also drive program design.  The discipline developed in TDD of understanding how customers will use specific functionality will indicate how to create the test cases, and the focus on how the interface works before implementation occurs will create a better program.

TDD works best when working with programs with a more modular design, but can be difficult to apply with programs that integrate to databases, because in that case full functional tests may be required to determine success or failure of the code.   Another potential weakness of TDD is when the tests are created by the same developer who created the code.   This is one of the reasons why in XP, programming is usually done in pairs, with one programmer creating the code and the other programmer reviewing it.   The second programmer is probably the better one for creating the test conditions, etc., described in step 1 above, because he or she understands the code well enough from having reviewed it, but has another distance from the code writing process to create test conditions which will effective test the code without missing the developer’s “blind spots” regarding user specifications.

Management may object to using the Test Driven Development (TDD) tool because tests increase overhead, but TDD can be soon as a tool which simultaneously increases quality while reducing risk, so it can be seen as beneficial to the bottom line of a company in the long run.

The next post covers the other widely used tool in conjunction with various agile PM frameworks, namely Agile Modeling (AM).

Filed under: Uncategorized |