Is manual testing dead for good?

We all know it and likely we’re all more or less into automation testing for some time now anyway. Automate whenever possible resonate all over IT industry! Or even more ‘ambitiously’ – no more manual testing – let’s go for 100% automation!

I’m not saying there is something wrong with automation at such as a concept but before we wrap up let’s consider few points.

Manual testing is an activity which includes software testing manually aka without using any automation tools or scripts. In this case testers are taking on a role of end user and tests from user’s perspective. Some testing techniques specifically encourages or are designed for manual testing. Think of exploratory testing or UX Testing.

Opposite to that automation testing is an activity where testers write scripts in certain form and use some software to run them. Notice that this process usually involves automation of a manual process. This form of testing rely on pre-defined conditions that will prove that while having certain input data A & code B - the result is always C.

From the nature of this - automation is usually used to re-run test scenarios that were used to be performed manually – quickly and repeatedly – think of regression test suites. Now though regression tests are one of first area which shall really be automated – they are not alone. There are other perfect candidates such as performance/load/stress test suites for example. I’d personally think of all non-functional form of testing when looking for initial candidates to automate as well as functional testing on low level of testing phase (Component).

Now when to automate and when not to?

It makes sense to think of automation when:

• You have enough time

Test automation, namely planning & preparation phase takes time. When you compare it with manual testing you will discover that there the most time consuming activity is actually execution itself. Basically you need to be sure of reaching positive automation ROI.

• Requirements are stable

When you start with the automation  specifically on agile project it’s very difficult to match with the changes. This may suggest that automation is not  suitable for agile projects. No, that’s not the message here at all and in fact it would take on article itself, the point is just that with requirements changing frequently team will generate vast part of effort spent as obsolete. Usually when major level of flexibility is required it would be easier and faster to execute tests manually.

• Large and long-term projects are involved

Such setup gives an ideal environment for automation. The ‘extra’ time invested into planning/preparation of automated tests can be justified in such case. In makes however no sense to automate when your project is short-term. Simply put a price to automate such project - it would be likely too high for ROI and value offered. Manual testing will be cheaper.

• Areas of projects which are heavily exposed to potential regressions are noticeable
  

Shall your project have areas which are at risk of potential regressions and you want to test them frequently to make sure there are no regressions then by no means go for automation as much as possible.

• Usability is not the concern
  

Automated tests will easily find errors in the code but they will never tell you how user would interact with certain feature or how native is that to use your software.

• Performance testing is the concern

Surely you can outsource to 1000 contractors to generate certain load to the system but maybe it would be easier and ultimately cheaper to automate it with virtual users with close to no degradation of confidence in quality.

So?

Is manual testing still on? Or is automated testing an irreversible evolution of manual testing?

Automated testing shall not be understood as linear evolution in my opinion, well yes automated testing has some indisputable advantages, but manual testing simply is and will be more beneficial in specific cases. It should complement automation testing not the other way round. To repeat myself I believe that real end-users will find a lot more ways of breaking the system that tester could ever imagine unless you have test team with high level of independence and certain UX testing knowledge.

By understanding your needs you should be able to find and fit the best for the situation in order to help you with the overall quality of your product as well as productivity of your team.