[khyryk]

I think that for the most part, reality killed it. Manual testing can slow down the development cycle considerably when bug fixes are streamed through, during system integration testing, etc. A small change can cause the manual testers to groan and declare that they have to recreate a dozen scenarios manually, which includes lots of data prep -- merging in a large change a short time before a planned release is even worse.

Automated tests never get bored or tired, and they can run constantly or exactly when needed; manual testing depends on the mental state of the tester and how prone they are to making small mistakes in general -- a bad night can result in an error in a non-reversible manual step that destroys, say, 2 hours of prep work if detected early and 12 hours of total work if not, causing chaos and confusion in the dev team. A manual test doesn't indicate that it has failed without someone going through it again, and I suspect many orgs don't want to do 20,000 manual tests during system integration.

Automated tests generally survive team reogs, departures, and memory loss; unless manual test scripts are meticulously documented, they may lack implicit assumptions held as a result of working on the same system for 5 years.