Defect Driven Testing (DDT) is the process of covering discovered defects/bugs with tests. It has some similarities with Test Driven Development (TDD) but is specifically for the act of writing test cases for existing code defects rather than writing test cases for new functionality that does not yet exist.
Note that DDT is often talked about from a QA perspective, but it is a simple process that developers (the people usually fixing the bugs) can also benefit from.
The DDT process
When a defect is reported in your code base:
1. Write a test (ideally a unit test if possible) to replicate the defect. The test should be written to test what the code should do in a certain scenario. So upon running the test it should fail (go red).
2. Fix the defect in the production code.
3. Run the test, it should now pass (go green).
4. Defects often cluster together so if possible try writing other tests for similar scenarios to catch any other possible related defects.
You can now safely say that you have fixed the defect in question and the fact that an automated test now exists means if the defect were to return then the test will catch it!
