How many times have you had the following conversation, or something like it:
Tester A: "Look at that bug; it's pretty straightforward that the functionality doesn't match our test case. Why can't somebody do a quick smoke test before checking in the code?"
Developer A: "Well, yes I agree that's a bug. We just ran out of time; the schedule is tough for us, we did those most important verifications before we checked the code in; we made sure all Unit Tests passed, we made sure that the build is solid, and we wrote as many automated test scripts as possible but we didn't have enough time to cover that functionality. It's great that the testing team found that bug, we can fix it later."
Tester B (Test Lead): "But that costs a lot, we spent a whole day to manually execute all the functional test cases and found at least 5 obvious bugs. They could be identified even without looking at the test cases. Now we need another day for regression test after your team gets them fixed."
Developer B (Develop Lead): "But that's the reality, isn't it? It's normal to have bugs. We cannot avoid delivering bugs together with the code. That's why we have a testing team."
Ethan Huang tackles the topic of spending too much time finding and fixing bugs, and not enough time writing good code from the beginning. Does going beyond Test Driven Design
to Test Driven Requirement
help solve the problem? Find in this blog about Creating Bugs vs. Fixing Bugs.