Cute Wooks, as usual. Any ways I will toss in my 2 cents on the topic.
What is automated testing? It is a process of creating an application or scripts which perform a set of test cases against a piece of software with little or no human interaction.
What is hard about automated testing? The hardest thing we have come across is convincing our manual testers to use automated scripts. There is a huge trust issue to overcome. There is also a skill level needed. Automated test developers should be part tester, part developer.
Simple minds, Simple thoughts!
I figure if you have the courage to get out of bed in the morning, then how bad can the day be.
One thing that makes test automation hard is that people think it is the silver bullet / panacea to software testing.
Another thing that makes it hard is that the hype/marketing is directed at managers that don't understand the level of commitment necessary to do "good" automation, who don't realize that test automation is a parallel development cycle. This typically results in automation being foisted upon a testing team that is already overloaded (the worst thing is when well-meaning managers try to push a tool's use at the end of a project to help "make up" some of the lost time (*shudder*) ).
Yet another is that schedules, team skills and capabilities aren't usually augmented as needed to take into account the use of a test automation tool.
Summary: The human factor is what makes it hard. Learning the tool is easy. Knowing when to put it to use, explaining to your manager that it's not going to magically improve your product's quality, and that extra time and expense will be needed to put it into place, all of these are "what makes automated testing hard."
And now my two penny worth. First it is right you should search the forum first but the most difficult is coding in such a way that the original test script can pick up minor changes to the application and still carry on testing, basically the error handling side of things.
The convincing bit is ok (as in fairly hard) but if you can't create robust scripts from the start you will end up with shelf-ware and this my friend is where the skills come into it. You need skills to create scripts that if it (the test tool) encounters problems it can try and figure out what has changed. E.g. on a web page get the root xml document and see what elements are on the page then based on that, look at objects will require testing.
So a tester will inevitably become part developer (and who tests their work )