When it comes to the world of QA, automated testing is become more and more popular. In fact, a quick search of QA jobs on sites like Indeed, LinkedIn, etc. will show that the majority of these jobs now require automation experience with a language like Java, Python, etc.
This can prove daunting for testers with a background in manual testing, who typically leave the coding to developers. It can also be confusing to employers, who aren’t sure how much automated testing they need, and whether it can replace manual testing completely.
I’ve worked with clients who use 100% manual testing to great success, and those who attempted to do 100% automation, and had to re-think their strategy — so the reality isn’t always as black and white as it may appear.
The ideal combination is having both manual and automated testing, though the amount of each depends on your exact product/service and what your company’s software development life cycle is like. For example, if you’re constantly adding new features, you’ll need very rigorous manual testers. Of course, ideally you’ll also have automated regression tests set up, to make sure that the new features being introduced aren’t breaking old features.
What’s the Difference Between Automated and Manual Testing?
Okay, so you know that a company should have both manual and automated testers. But what exactly is the difference besides a vague reference to “writing code”? Let’s break it down with a simple example.
Manual Testing involves, well, manually testing the app or website. For example, if you wanted to test whether a login feature in an iOS app was working, you might pick up your iPhone, tap the relevant app, select the Login button, type an email address and password using the keyboard, and tap to proceed — then observe whether it logged in successfully.
Automated Testing entails writing code to create test scripts that could automatically do the above actions for you and give you a report of any bug — scripts that you could run with the click of a button. (Or, if using continuous integration, whenever there’s a new build or at a certain time)
Generally, to do automated testing, you need to have some programming skills — for example, knowledge of Java (which will enable you to write the test script code).
Is Manual Testing Dead?
In a word, no — or at least, it shouldn’t be. Manual testing and user experience consulting should still play a huge part in any QA team.
It’s great that more people are learning automated testing — above all, because it provides extra stability to the QA process. It can automatically alert the team of sudden bugs, and save a ton of time (and rote work!) with regression testing. There’s no doubt that it’s incredibly useful to have solid automation framework in place. However, I encourage both QA testers and tech employers to not abandon the importance of manual testing, for several reasons.
Good QA should be about proactively improving the product or service — not solely reporting obvious bugs. Manual testing has the power to go beyond basic “is this a bug or not” behavior testing. The power of having QA actively identifying areas of improvement and advocating for better user experience can’t be understated. It may sound like a luxury when funding is tight, but rest assured that it can have a huge affect on a company’s bottom line. As Fast Company shares:
For brands to compete for attention now takes something greater than mere presences in the right channels or support for the most popular devices. User experience is now becoming a critical point in customer engagement in order to compete for attention now and in the future.
Particularly in the win-fast-or-fail world of startups, user experience needs to be on point — and automated testing alone can’t cover this. By forcing manual testers to become automated testers, companies are overlooking a goldmine of talent and creativity.
So, the answer to the overarching question? (Or, in internet terms, TL;DR!) An ideal Engineering department should have both manual and automated testers, respecting the different strengths that each brings to the table.
Happy testing — manual or automated!
Author: Wes Silverstein