Defect Driven Test Cases

Recently I was reading something around test driven development and how it has been further extended to behavior driven development. I started to understand the philosophy behind behavior driven development pretty quickly. The Given,When,Then format for writing a scenario is an straightforward and easy input for developers to build their code around.

Now I am thinking that similarly we should also start doing defect driven test cases. So the current practice for a tester is , generally, look at the requirements , analyze the testing aspects from a story card (I think only agile projects now), identify testable items and write them as acceptance cases. This is good and required but what about System Level test cases, integration test cases should they be written upfront ?. Now if the quality of test cases are so good that you get at least 30 percent of defects from executing your test cases then I think writing test cases before doing actually testing is worthwhile but if the objective of writing test cases is to create more documentation to cya , or to be able to create an unnecessary deliverable from the testing team then really its futile. Instead what we should do is "Exploratory Testing". Do Exploratory testing on the in system and integration phases and then based on whatever defects found during system testing or integration testing and create test cases for that particular defect for future testing and regression. This will do two things for the tester. 1 - Invest less time in writing useless test cases and 2 Write test cases which are more specifically targeted to previously found issues on the application in a given module/part/application.

I will continue on this thought further but for now...I think defect driven test cases is the way to build your test repository from a test case/scenario/test data/and app issues perspective.