A great way to reduce rework costs is test-driven development, a process that states: The earlier you catch a problem in the software development lifecycle (SDLC), the less expensive it is to fix.
Here are some key points to understand the benefits, drawbacks, and common implementation mistakes.
Breaking Up The Premise
With TDD, you can focus on testing from the beginning. When creating products, developers define upfront what they need to test and how to test it. What does a product feature need to do and how will we know it’s good? What tests must it pass to be complete?
Before developers build a feature, they write tests. They start with the simplest case and then add complexity to ensure that every possible scenario is covered. The feature must pass the old and new tests before a developer commits it to the code base.
How Is Test-Driven Development Different From Earlier Processes?
TDD encourages cross-functional collaboration. Before, developers wrote code and QA wrote tests. These functions were silos. Even within a single team, developers used varied criteria to decide when to commit code to the base. Some developers felt testing was 100 percent QA’s job. Others wanted to make sure their code worked before sending it to QA. The individual developer decided how much testing to do (or not to do).
This led to inconsistent quality levels coming out of development, resulting in considerable rework, which impacted schedules and budgets.
What Are The Benefits Of Adopting This Approach?
TDD is less expensive than the siloed approach. Why? When developers add new code to the base, the code works and doesn’t break the base.
The test-driven development mantra “keep it green” means the developer must ensure that the code passes the test before submitting it to the base. If it doesn’t, the developer can keep working on the code until it does.
A siloed approach to development means that coders have already moved on to the next piece of functionality by the time QA finds bugs. This leads to downstream consequences, anything built later that relies on the problematic code may also need rework.
What Are the Downsides?
The main downside of TDD is that it takes extra time for the SDLC to be completed. Software developers now have additional code (tests) to write and maintain. However, executives benefit from taking the long view. By spending a little more time on the front end of the SDLC, it’s possible to shorten the entire SDLC significantly. Additionally, TDD improves the quality of software releases, which can lead to higher customer satisfaction and more revenue.
Another downside is that complex product development efforts may require writing additional proprietary frameworks to test how the product interacts with third-party tools and utilities.
What Mistakes Do Organizations Make When Implementing Test-Driven Development?
There are three common errors that leaders can prevent with the right planning and communication:
- Writing poor test code: Software developers need to treat test code and test utilities as production-level code. The test is going to live as long as the production code, so it needs to be well-written. Taking shortcuts can come back to bite you in the future.
- Relegating testing to junior staff members: Many companies position senior engineers on the production line. In TDD, however, it’s important to have experienced developers looking out for problems. As a code base grows and becomes more complex, you need people who know where to look and how to organize code.
- Allowing broken tests to stay broken: Keeping bad tests will play against you over time. Some teams allow tests to break and then leave them broken, sprint after sprint. The damage from this approach compounds over time, and the longer you allow this to continue, the more expensive and time-consuming it is to fix.
Before software testing, developers might have manually tested their code by submitting it to production. Often, the code would break in unseen ways, causing errors that would be hard to fix.
Lines of code execute based on different situations. It doesn’t take long to reach the point where programmers cannot keep all the code and scenarios in their heads. If multiple people are contributing to the codebase, no individual can track all the ways the software interacts.
TDD helps you find bugs in the new code. Some tests have interactions with the new code, some don’t. This can be confusing for developers who have to keep this information in their heads. TDD frees up their brain space for other important problem-solving activities.
