Software Testing  Manual Testing  Testing  
   Technology    Programming

5 Points to Prove Manual Testing is not Dead

 JUNE 3, 2019   by SainyBanerjeePal

Just as there is no replacement to the human eye, there is no replacement to the manual testing in the IT industry.

Be it due to the user experience, exploratory testing (which can be only done by manual testing) or the 100% test coverage, it is probably next to impossible that one eradicates manual testing from the industry.

Today, when all the manual testers fear for their future career scope, with the advanced automation suites emerging, let us not forget the fact that automation testing too, needs manual efforts initially and even in between the execution.

While automated tests focus on codifying knowledge we have today, exploratory testing helps us discover and understand stuff we might need tomorrow.

There is no doubt that automation testing has eased many lives and saved many working hours of software testers but then, these days, a humble manual tester craves for attention.

'Why should a manual tester be valued anyway, when anyone can do a manual testing task' , state many in the IT industry.

If you are a manual tester and are subjected to such queries, below are the 5 pointers which you need to remember so that you could remind others of some facts that they need to brush up with,

Manual testing vs automated testing

1. What about the issues which are visual, behavioral or that are least expected?

When the color of a web page, keeps changing for a few seconds when a user clicks on an object, will the automation scripts take it as an error?

Automated test scripts can't discover usability issues and user interface glitches as efficiently as a human does.

A lot of times bugs are actually found by testers when they were looking for something else, will this be ever done by automated script?

An automation testing script can notice only those errors that it was programmed to find, but a manual tester's eye wanders for errors.

2. What about the restrictions in the test to certain boundaries in automation testing?

When you have been given a system to test, you do draft the test scenarios and test cases, following which, you would be carrying out your test execution.

Now when you have started execution, in automation test, you will have the test execution only on the scenarios that you initially defined.

But in the manual test, you can literally "explore" the system. Even while testing, you will be free to check what happens when you test it differently. In other words, you will never miss the ad-hoc testing.

Moreover, if you are working in a project that is following Agile Methodology, what will you do to your classy automation script if the requirements change at the end of the sprint? We pray it does not, but who knows?

Under such circumstances, when you need to have a test result in a short time, the only savior, most probably, might turn out to be a manual tester.

3. How to correct the false positives and false negatives in the automation test without a descriptive test report?

Once the automated test scripts are executed, reports are out, you sure might find some errors with the descriptions which are simply objective.

In order to understand the problem in detail both conceptually and contextually, a manual tester has no match.

When a manual tester executes his test cases and drafts his report, it is found to be a lot more descriptive than that drafted by the automated scripts.

The manually drafted test reports explain the problem, the root cause, and suggest optimal ways to solve which might not be the case with automation test reports.

4. Will a small project be able to afford automation testing?

Not all the projects in the software domain will be high end or of huge size.

So when the project is small and the budget is tight, how much feasible will it to pay for the automation software, associated maintenance, and management costs incurred due to script writing and rewriting?

When we have long term projects and big products, the higher costs can be worth it, but for shorter, smaller projects it’s a big no-no as it might lead to wastage of both time and money.

Also when you are calculating the potential ROI for an automation purchase, you have to keep in mind the added man hours.

5. What happens when the scenarios are too complicated to automate?

Think about testing the gestures, tap, shake, CAPTCHA, and video control based trigger actions using automated scripts?

It might be possible but will need a lot of effort and time.

Furthermore, will you be able to guarantee the accuracy of a human tap by an automated script?

With all due respect to the automation skillset holders and the benefits that the automation testing bestows, sometimes a manual tester provides a lot more value than just knowledge of how the product is currently performing.

The last word, therefore, would be, a perfect blend of the manual test plus automation test perhaps will be of great help as you design your QA strategy for any software testing activity.