Is manual testing dead?

You might have heard the statements- 'Manual testing is dead. In agile, there is no place for manual testing. Testing need to be 100% automated.' 

I have also been part of these discussions and sometimes found it hard to explain why I don't agree to this. In my view, these may become a reality in future, but certainly not true for now. Let me explain it, but before that we need to come on the same page.

First we need to understand what is testing. Is it only regression testing? Is it only scripted testing - testing the AUT (application under test) against a checklist or test cases? As per one school of thought, both of these don't represent testing - these are examples of checking (read here for details). Real testing means exploratory testing. Even if you don't agree to this terminology, it brings up the point that testing does not mean only scripted testing. 

But why do we need exploratory testing? Why a tester cannot think of all test scenarios and document/ automate them before starting to execute them? Doesn't this argument remind you of Waterfall - the requirements must be frozen before design phase and design must be frozen before coding and so on. Needless to say this doesn't work in reality and that's the reason why Agile is becoming popular. Sadly, some of the Agile practitioners themselves advocate sequential execution of testing (understanding requirements, writing test scripts and then execution) - doesn't it sound like waterfall of testing process? So, if you agree that exploratory testing is desirable, you need to agree to the need of manual testing - how can you automate something, which you are going to learn while exploring the Application under test.

Now let's come to second point- Is 100% test automation possible or rather a basic question - can a test team perform 100% testing if they are not under unreasonable time and resources constraints? If you are not sure about the answer, please read The Impossibility of Complete Testing. If you can't test 100% even without any constraints, how can you automate 100% under time and resource constraints.

One may argue that if you are developing unit test cases with high code coverage along with integration tests and automated UI and functional tests, manual testing may not be needed. While I agree that testing at unit and component/ middle-ware/ webservice/ database level (in short at all levels) is desirable and should be done, it does not add up to 100% testing. The fact is that even if we add manual testing to this combination, that would also not make it 100% testing.

If manual testing effort doesn't help me to achieve 100% testing, then why cannot I do away with it and spend my energy only in automation? The reasons are: A human tester can understand the end user better, has better cognitive ability, can take decisions based on risk assessment, can communicate and understand developers better, can find out the implied functionality and missing requirements. A computer can replace a human testing the day it becomes better in all these aspects. But by that time, probably coding would also be automated.

By the way, can a CEO be replaced with a robot?  Not currently. But who knows the future? 

Update 1: I have heard this statement 'Manual testing is dead' in many forums and have reproduced the same without any attempt to sensationalize it. My fellow Test/ QA Managers would also have heard similar statements. Also, in this post, I have not mentioned that developers cannot or should not test. In my view, there are both pros and cons of only developers testing or only specialized testers testing. But, that's a topic for different discussion.

The only point I wanted to make was this - even though manual testing seems like old fashioned word, it cannot be wished away. And if you are not allocating time/ resource to do it as part of story/ feature completion, you are taking a risk, which you should know.