A good question to ask.. - Gave birth to this thought while standing in today's lunch queue --- and in a way, this did end up as 1 kind of "food for thought". :)!!!
If I am going to look back at every testing article that I have read over the past few months, or every testing seminar that I have attended in the past few months - They have always offerred their thoughts on how to have better automation which would result in minimal rework.... Would this mean that the manual tester is going to be buried shortly? Does this mean that every test engineer should start developing automation skills for his survival?
My answers to these questions would be - NO & YES. ---> respectively speaking!!!...
Answering the 2nd question first, I really think that every test engineer should start developing automation skills without a second thought. That is the only way forward for him to survive in today's world. This would also help in career growth and in a way, serve as supplementary skills . This would give him the edge when compared with another tester, who does not have knowledge of automation.
Secondly, being in touch with automation tools would also keep the tester aware of what is happenning in today's technology world and make him more tech-savvy. But, having said that, it is not easy for any person to start developing automation skills overnight. This is something which can be done over a period of time - 6 months to a few years. He would need to chart out his journey in the arena of automation testing and plan on regular self-evaluation till the goal is reached.
Now on to the 1st question - will the manual tester die sometime? Is the new decade going to herald the death of the manual tester? Though the advancements in the area of automation testing tempt me to answer in the affirmative!!!. But, try as I might, common sense prevents me from saying YES. The manual tester is indispensible in any project. He is the one creature that nobody wants, but nobody can live without :).
It is impossible for 100% automation to be achieved. Ask any true software testing practitioner and he would subscribe to the theory that manual testing would account for at least for 40% of the defects found. - (this is if you have an effective tester in your team, who practices the art of software testing in a manner similar to how a doctor practises medicine, or a lawyer practices the art of law in today's world).
Most of automation testing world revolves around effective regression testing, and it's advantages or cost benefits are seen in the long run. When we receive the first build, it takes a manual tester to be able to find out most of the defects.
That brings me to the question with which this blog started - 1 differentiating point for the true tester and the fake tester - When you receive a new build and the tester finds a few defects, what would be his immedieate action?
Fake Tester - Would be more inclined to find a few defects , shoot off an email saying that the build has broken and that he cannot test anymore and be off to visit other websites while the dev team fix the defects!!!
True Tester - would be able to detect most of the high severity/priority defects, apart from emailing the defects he'd ask everyone to attend a conf. call to discuss the defects, do a root cause analysis of the defects and work on defect prevention in subsequent builds!!!
Having said that, the next question to me would be if I practise all that? Well, to be honest - I don't, and that's why I remain, the perfect specimen of the fake tester!!!!!