CERTIFIED: ISO 9001 | ISO 13485 | ISO 27001
CERTIFIED: ISO 9001 | ISO 13485 | ISO 27001

TDD Series Part 3: Four Reasons TDD May Not Be Right for Your Project; Some Critical Questions to Ask

TDD Series Part 3: Four Reasons TDD May Not Be Right for Your Project; Some Critical Questions to Ask

In Part 1 of this series, I presented a brief description of Test Driven Development (TDD).

In my Part 2, I looked at six reasons TDD can help your software development project. In this follow-on article, I will look for some reasons Test Driven Development may not be right for you and your project, and some critical questions to help you decide.

1. Your Project is Exploratory or “Proof-of-Concept” Only

Test Driven Development (TDD) requires maintenance of tests. Therefore, it tends not to work as well for certain projects, specifically:

  • Exploratory or research-driven projects
  • Proof of concept projects, where some of the development may be abandoned

In Test Driven Development, we must maintain the test code as well as the production code, and this maintenance takes time. I’ve found that with projects where the requirements are less understood and change more frequently, the time and cost of test maintenance is considerably higher.

For these kinds of projects, the benefits of TDD can be somewhat lower. As requirements are changing, test suites and traceability matrices generated from the TDD process become invalid. We end up with high code coverage on software elements that ultimately do not make it into the final product.

2. You Are Developing a Product Workflow or GUI

TDD often is not recommended for projects that focus on the user experience (UX). In these projects, design tends to be more fluid, especially with constant customer interaction and feedback.

Rather than TDD, UX projects can focus on prototyping storyboards and wireframe mockups that are sent to users for review, and decoupling the display from the logic.

TDD can still be applied to GUI projects, but automating GUI tests can be costlier than manual testing due to the complexity of interactions.

3. It is Not Right for Your Software Team

Consider your team. Test Driven Development does not work well if:

  • The developers and testers are not enthusiastic about the process. There is an up-front cost due to the learning curve, as well as the time spent writing the tests. This additional overhead can make each individual feature take longer. If the team does not know what to expect, they may grow frustrated before they start to see any savings or other benefits on the back end.
  • The team does not have extensive experience writing good tests. TDD will work best if there is at least one expert on the team who can guide the process. Badly written, fragile, or unnecessary tests can add significant maintenance overhead and can slow the team’s momentum. Ideally this ‘lead’ person will also have some experience with software architecture to help the team design for testability and better focus the testing procedures.

4. It is Not Right for Your Organization

Similar to knowing your development team, consider your organization.

In point 3, we asked if the developers were enthusiastic. Are other groups, such as Marketing, QA, and Regulatory also supportive? Is there high-level management support for the process change? Without organizational support, the additional cost to develop the test framework prior to any product code may be viewed as engineering time wasted. Even worse, management may be unwilling to accept what it sees as a delay in product completion.

Also, consider how developers are evaluated. Sometimes, practicing TDD will cause a developer to drop in performance metrics, due to the nature of the metric and the increased up-front time needed to implement a feature. Therefore, certain metrics may be misleading in terms of how a developer is actually performing when using TDD.

Finally, consider the organization’s testing framework. Thorough testing is good practice, regardless of your industry, so your organization likely has tools and procedures in place for requirements tracking, traceability, and unit and verification testing. However, if this is the first time your organization has tried TDD, you may find that your existing testing framework is no longer up to the task. Moving to TDD will require a hard look at your existing framework and may require an investment in identifying, acquiring, and learning a new set of tools. Having provided testing services in concert with its development work for scores of clients, Syncro Medical can help assess your testing framework and recommend appropriate tools.

Critical Questions:

To summarize, here are some critical questions to ask before deciding to use TDD for your project:

    1. What kind of project is this? Is it more exploratory in nature or are requirements well defined?
    2. What is the phase of the project? Are we still defining system features and requirements or do we have a good idea about the feature set?
    3. Is this right for my team? Are the developers enthusiastic about this? Is there at least one person on the team with sufficient test writing or even prior TDD experience?
    4. What level of testing do we need? Are we working in a safety-critical industry where code coverage and traceability are especially important?
    5. Is this right for my organization? Is management enthusiastic about the process? Are some initial delays acceptable as developers learn the process?
    6. Is there confidence that the up-front investment will be justified by the expected benefits? This is especially important to ask for the first TDD project in an organization.

Test Driven Development (TDD) can be a powerful tool, but also there are some important factors to consider and questions to ask before deciding to use it.