Why don't managers understand time issue in testing?

I read Michael Bolton's blog entry about "Why is testing taking so long?" and started thinking why don't managers understand it. So I came up with following aspects why managers won't tend to understand it completely.

a) They tend to think most of their days in rational aspects where is little room for unknowns and even little room for luck -> But testing itself consists of investigating unknowns since usually testers know very little what to expect from software they have to test. That's why it is hard to estimate time it would take (see "needles in haystack" aspect of testing I describe in previous posts). And every time we discover new unknown and investigate it, then it spends extra time and again has devastating effect on plan for testing. But if we wouldn't investigate unknowns then we wouldn't be doing much of testing. We would only do checking (see Michael Bolton's blog entry "Merely" Checking or "Merely" Testing. I won't say that checking isn't necessary but it is not testing.

b) They don't tend to understand that every time we discover a bug, we have to spend much more time for it - we have to investigate it, report it and check if it is fixed afterwards. So the point would be : "Good tester tend to generate more and more work for themselves by doing their job.". It might be hard to tell them that without provoking them to say : "why do you find so many bugs then?". It can be explained by this logic: since their tasklist tends to get shorter when they do their work efficently, it is hard for them to understand that ours tend to get longer when we do our work efficently.

c) Belief that written plans (and following them exactly) helps to solve or prevent most problems. But plan is a model. All models are wrong, but some are useful. Meaning that sometimes it helps us to plan a little ahead. But with so much variables as in testing we can hardly do it more than few days to maximum of few weeks forward and believe it is accurate and still useful after that time. Testers tend to make the plan usually quite short-term - "I see what happens after I try this combination" is a plan. Actually really good plan. If you have to use session based testing then of course planning is needed. But plan doesn't have to be 4 pages long document with detailed descriptions everything needed to be done. And our plans tend to fail... Outstandingly... This is acceptable. For us... We still learn... But for managers this is usually disaster. "What do you mean you are behind schedule more than 1 week after 2-3 weeks?"

d) Belief that preparing lots of documents which tell us what to do, increases the speed of our work. They put too much credits that every task can be prepared, measured and estimated before completing them. Since their work is based on planning (and it is required from them) they tend to think that they could expect the same from us. But if we know that there is a bug by planning to check it, then we ideally can fix (or report) it before it even gets into the software. It usually doesn't work that perfectly, but with certain reservation we can use it as a model. I personally have found about 60-80% of bugs from places not described in test cases or in any other documents. The issue is finding the bugs we don't expect. Again the unknowns are the involved.

So only advice (is it good or bad, you have to decide)I could give you is: If you don't understand what is expected from you, your manager annoys why testing takes so long, why do you find so many bugs, Why are you behind schedule etc then ask him/her - "Do you want me to check the software or do you want me to test the software?" (Don't forget to explain the difference between checking and testing).