Why do we keep writing (manual) Test Cases upfront?

There are at least 2 ways how developers could write unit tests: before code (TDD) or after code is ready. The same applies to writing manual test cases and test scripts (given that we decided to write them at all). There are many benefits of writing up-front: you could review, better plan (schedule) and control, test faster once code is ready, etc. The draw-back is only one - you spend more effort (budget)… (well there are actually more but let’s forget about them now). But do you know how much more? 4 times…? I’m happy that I’m not the only one as I read in year 2009 articles that

In many organizations, before any testing can begin, testers must develop detailed test cases or scripts from frozen, documented requirements and then get them signed off.

Though there are certain benefits of doing so there are a number of draw-backs. One of them is the cost. Do you believe that it costs 4 times less (in terms of resources) if we write down the test cases during test execution, not before? Writing them is really a good way to kill time. Indeed I remember one of my first surprises when about 10 years ago I started test manager career. I saw a test effort estimation template that calculated test effort based on number of test cases. The effort to write test case before “working prototype is ready” was 4 times as big as “with working prototype ready”. The surprise was that 1) this was an accepted wisdom 2) many projects still used to chose the expensive way of doing things. I’ve recently reviewed and signed-off upfront written test cases. I’ve spent a lot of my time reviewing them and recommending ways to improve coverage and they implemented all my ideas. (I felt so smart…) There is but a one BUT. They spent 2 months to script them, run the first time report bugs and retest bugs. Now they plan to regression test all the test cases developed so far in 2 days. 2 months effort aimed to plan/manage 2 days of work?! You are joking, aren’t you?