[Albert's reply.
Hi Trish.
I appreciate your response and thank you for the examples]

1) Manual tester hired and told to learn automation. The strange logic by the manager here was “I learned German from a book and it wasn’t that hard, so she can learn Java from a book.” Automation was eventually abandoned.

[Albert's reply. I guess, the point that manager missed is that learning German from a book didn't teach how to write a book in German. ]

2) Assigning developers to test automation. This worked to an extent, but the quality of test cases was not as good as automation testers would have made them. The scripts didn’t hold up well against unexpected application changes and the choices of tests to automate were not always ideal.

[Albert's reply. A more or less satisfying [project's needs] example I’ve seen was programmers following requirements designed by testers for testing scripts. But it was expensive time- and resource-wise; plus filled with redundancies, as automated testing flow closely followed manual test cases]

3) Set up consultants. A consultant was brought in to create an automation suite for the test team, who were unfamiliar with the tool. He recorded a small suite of tests using the record and playback tool. The team ran the suite once at the start of the project, and then tried running it again at the end of the project – everything failed with errors that nobody could comprehend. The suite was quietly discarded.

[Albert's reply. Unfortunately, such organizational fails are counted as test automation fails...]