Part 3: Four Reasons Test Driven Development May Not Be Right For Your Project
1. Your Project is Exploratory or "Proof-of-Concept" OnlyTest 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
2. You Are Developing a Product Workflow or GUITDD 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 mock ups 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 more costly than manual testing due to the complexity of interactions.
3. It is Not Right for Your Software TeamConsider 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 OrganizationSimilar 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 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:
- What kind of project is this? Is it more exploratory in nature or are requirements well defined?
- 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?
- 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?
- What level of testing do we need? Are we working in a safety-critical industry where code coverage and traceability are especially important?
- Is this right for my organization? Is management enthusiastic about the process? Are some initial delays acceptable as developers learn the process?
- 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.
At Syncro Medical, we work with our clients to identify the overall development and testing methods that are compatible with their internal process and that best meet their development objectives. Over many years we have developed a reputation of excellence. Please take a look at our most recent client feedback. If you are planning a medical device software effort, talk to us first.
Comments are closed.