Why Bother With Manual Testing?

These days, we have a lot of concepts and tools for automated testing at our disposal. Although creating and maintaining them is not easy, there is the massive benefit of repeating them at almost no cost. This raises the question of why we should still bother with manual testing. Has it become a bad practice and a waste of time?

In my opinion, the answer is no. Manual testing still has some value. Here is a list of common use cases that I consider perfectly valid for manual testing:

Creatively (mis)using the software to uncover bugs

Think about corner cases that are different from the normal path of intended usage. Developers, product owners and designers usually have some intended ways of usage in mind. Sometimes they think about corner cases, but they might not catch all of them. To illustrate the point, consider a simple web shop: A user searches for a product, picks an item from the result list, and puts it in their cart. Then checkout and payment happen before the order is shipped. A creative tester might think about corner cases like these: What happens when I put all the available units of an item in my cart? Can I buy all of them when I have enough funds? Should this be allowed? What happens when I put the last remaining units in my cart and another user does the same? You get the idea.

Testing a small change or fix in the absence of automated tests

Ideally, there should be a foundation of automated tests that you can adapt or extend to verify a software change. In practice, though, many software projects are far from ideal. Automated tests might not exist, or there is no existing groundwork for the area that you might want to test. In this case, performing a manual test can be much quicker and simpler. Let’s say you are moving a button from one user interface page to another where it fits better. Assuming there are no existing UI tests, it is much quicker to test this change manually. Of course, it might be a good idea to start with UI testing anyway. But it will probably take a lot of effort, which you might not want to accept for a small change.

Prototypes, proof-of-concept software and similar

If your first goal is to have a demo or prototype application to show, it might be faster to start out with manual testing. In this case, there are very limited expectations in terms of functionality and correctness. The main purpose is to validate an idea and have something to show and try out. This can be a valid use case. However, once the software is further developed or moved to production, I would strongly recommend creating an automated testing strategy. Otherwise, it’s easy to end up with a large code base but zero automated tests.

Summary

In a nutshell, my recommendation is the following:

Use manual tests as a complement, not as a replacement for automated tests.

As we already discussed, making suitable tradeoffs is an essential part of software engineering. This applies to testing strategies, too. Use the strengths and weaknesses of each type accordingly. Automate repetitive tests as well as you can, especially for critical features and use cases. Use manual testing for discovering new corner cases and checking software from the user’s perspective.

What is your recommendation about manual versus automated testing?

#SoftwareEngineering #Testing #Efficiency #Bugs #TradeOff