Automated or Manual Testing

"Better" implies a value analysis. Some folks are good at manual testing andpoor at automated testing simply due to their make-up. Trying to trainsomeone who really is not cut out to be an automated tester will yield poorresults. A good automated test engineer needs the predisposition of atester, but also the mental composition and interest of a developer.Finally, in the U.S. at least, automation test engineers are normally paid apremium, averaging 20% more in salary, than manual testers. On average,remember, so there will be exceptions in industry segments. The reason? Theyhave to know some programming and development.Regarding the relative stability of employment you think manual testersenjoy compared to automation types, I assert that is domain specific to adegree, but more probably company specific. If you work for a company whodiscards testers proficient in Tool A when they bring on board Tool B, thenyou need to look for a job elsewhere. The management of such a company is ingrave need of a clue. The specific techniques for Tool A and Tool B will bedifferent, but the approach to test automation, the design and architecture,the discipline and engineering of it, is directly applicable regardless ofthe tool used. And that experience is more difficult to find in employees. Ican teach just about anyone with half a brain (which, from my experience,excludes some half of the candidates) how to use any tool to a basic anduseful degree of proficiency. Only a few will ever have what it takes toprogress to intermediate proficiency. Most companies choose one solution andas that improves or changes, they make sure their employees improve andchange too. It is an investment that is in the company's best interests. Ifthe underlying technology of the product radically changes, then the testapproach -- and tools used to implement that approach -- probably will haveto change as well. Client-server vs. web browser-based would be a commonexample. Moving from C++ to Java is another example.Regarding domain specific cases for stability, it is the knowledge of thatdomain and the prior product versions that makes the tester valuable morethan the fact that the tester is a manual tester or not. I worked for acompany where the QA testers pretty much had to have the equivalentknowledge base in geology and petrophysics of at least a Master's degree.Several were PhD level. THAT knowledge and experience of product, or how theuser community used the product is what made them employable at thatcompany. How they tested the product was less important.One last thought: many companies are sold a proverbial "bill of goods" bysaavy sales reps from the automation tools vendors and are convinced Tool Ais the complete and end-to-end solution to all their testing challenges.When it doesn't pan out, due to lack of training, lack of organization andarchitecture, etc. etc., the company management tends to want to jettisonthe tool that let them down. The tool users often are jettisoned as well, aspart of a failed project. This happens all too often. Then the next "silverbullet" be-all and end-all Tool B sales rep comes along and convinces thecompany that IT'S product was what the company should have had all along.New tool and new tool users come into play. Normally, the same resultoccurs, because it is the test management of the company that doesn't knowhow to implement test automation, and the same guys are there time aftertime after time, making the same mistakes over and over.