This is the discussion that took place on Software Testing Club forum.
What are the most important things I see in it and what comments I feel necessary to give ?

End-user perspective

I’m looking for something that I can use as an “out of the box” solution

Apart of computer software world this is the single most popular approach. If you want to drive you get a car. You are not getting “make-your-own-car” toolkit. If you want to go for a dinner you’re looking for a restaurant, and not cooking classes.
So when you are looking for a product – you are looking for something finished and ready for use.

However, if you got a minor leak in your kitchen hiring a plumber is not the only single way resolving the problem – and we’ll talk about that.

Tester is the End-user

Testers have a whole bunch of responsibilities in Software Development process. Testing is one of their “majors”. And the major outcome of testing is test results that could be further investigated, analyzed, and interpreted.  So if Tester wants to delegate testing activity to someone or something then test results is the expected value.

Test Automation is not a product

Now looking back to the example with plumbing problem. You can’t buy in a store “Get-your-problem-fixed-without-hand-work” magical wand. If you don’t hire a contractor you have to get a toolkit, materials, – and still you have to figure out how to apply it.
Test Automation Tools and Test Automation Services are also separate and distinct things on the market. Buying (or downloading open-source) Test Automation tool allows to begin Test Automation process but Automation Tool is not the solution yet.

Test Automation is a project

Test Automation is a process of creation of automatically executable test(s). There are 2 general approaches:

• development of an executable script which is based on some programming language;
• creation of test instructions that are to be executed by a special program.

The script could be developed manually or created by using code generator. Developing scripts manually leads toward Data-Driven Framework approach. Using code generator for test automation is Record-Playback approach. Recorded scripts can be further enhanced with parameterization, checkpoints, etc. – however, it requires programming skills in order to understand, modify, and debug the code. 

Test instructions, or keywords, are much closer to regular English, and tester doesn’t have to care about strict programming syntax and rules.

Now when Tester (and Test Manager) decided on what approach to follow, it’s time to think of requirements for their software development project. Most likely, they’ll think of Usability,  Maintainability, Scalability, and Robustness.

…But, wait a second, look how much time was spent and still there are no test results?? Couldn’t we just quickly record all the tests by executing test cases manually and having code generated into the test scripts?
– Yes, you could do that but only to find out that those damn things don’t work. And while trying to make them working you will find yourselves in the middle of programming process, in debugging and refactoring stage, which is always a challenge.

Value of Automated Testing depends on how you invested in Test Automation

If you put an effort in creating robust scripts you won’t have to lose time 3 weeks prior to release trying to make the script working. If you put an effort in reliable verification and clear reporting you won’t have to stay overnight manually re-testing your regression.

And, finally, if you have done right test automation you have much more time to focus on a comprehensive testing and investigation that require human judgment and abstract thinking.

Instead of conclusion

That discussion is ended but the question is still open.
The demand in replacing manual work with mechanical tools is long and well known. The outcomes allow reaching higher technological and life level. On the other hand, occupation of manual work niche un-pleases some people as they are hardly challenged to evolve themselves in order to stay above the machines.

Post Scriptum.  In addition to ideas expressed, such discussions draw together other highly informative posts. Although not being really agree with Rob Lambert I liked much his post. And article by Joe Strazzere is “a must to read” for any QA manager thinking of setting up test automation.