Testing is an essential part of any software development, ranging all the way from basic testing of some code to make sure it performs the task at hand with the perfect inputs, right up to the rigorous regression tests performed by software houses working on enterprise level applications.
Testing usually comes down to two types: manual and automated. But what type of testing is better, and what are the benefits of each?
Pros of Manual Testing
- Faster for the short term. Manual testing can be as simple as just checking the appearance of an application on a mobile, which can be done very quickly by a human
- It's perfectly suited for usability and accessibility tests. Even the best automated testing tools for these areas is incapable of matching the capability of a person to identify issues
- Humans are far more flexible at testing things; things that don't even make sense. Want to know what will happen to your application if the user clicks a bunch of buttons really fast? That's hardly a typical scenario that is going to be built into many automated test suites
- Professional testers build up a large amount of knowledge over the course of their career. This is invaluable, and enhances their manual testing greatly
Pros of Automated Testing
- They are perfect for regression testing. If you've got decent coverage, then you can be sure you're not introducing new problems when you perform new work on the existing codebase
- They can be run incredibly quickly. Hundreds of tests can be run in seconds, faster than a single manual test
- Repeatable: tests can be repeated exactly the same each time, unlike manual testing which cannot guarantee that each test is 100% each time it's performed
- Some types of tests, like stress/load tests, are far easier to implement using automated tools. Simulating 1000 users hitting a website at once is simple with tools, but requires infeasible amounts of manpower to achieve with real people.
Cons of Manual Testing
- Very expensive. Performing each test takes time, and employees time is one of the most expensive resources a company has to pay for. The more manual testing performed, the higher the cost
- Humans are fallible, we make mistakes, especially when our minds wander. A human repeating the same tests over and over again creates the potential for more mistakes
- They take a lot of time to perform, sometimes measured in days. This doesn't lend itself to fast development cycles
- Sharing tests is hard, you incur handover time explaining your testing process to the next person
Cons of Automated Testing
- Upfront costs are high. It takes time to write the tests, and the benefits aren't immediately obvious until there's a good coverage
- Some things can't be tested. Even now, usability and accessibility tests are hard, and can't match the quality of manual tests performed by real people
- They can only cover the scenarios imagined by the person writing the tests. Developers, in the main, tend to be too logical, so we won't always create tests that emulate the kinds of crazy behaviour of a real user
One of the advantages I'm offered at my current job is the time to create proper unit and acceptance tests. This is great for me for many reasons, chief among them are that they give me a level of reassurance that I'm not introducing new issues, I can run them and be secure in the knowledge that they act as my first line of defence against regression bugs. Testing on this scale was never possible for me in previous jobs, as there was either no time or budget, and in my earliest days as a developer I wasn't even aware of their benefits or what they were.
This experience means I'm in a position to see a lot of the good and bad sides to both types of testing. The truth is, as I hope I've illustrated here, that there is no superior type of test. Each type is suited for various and often complimentary scenarios. The size of your organisation or tech department often dictates a lot of your testing choices, but there's no reason you shouldn't push to try to improve your testing by enhancing what you're already doing. Either way, it's clear that relying on one one method of testing is not enough.