Looking back on the history of software testing, automated testing isn’t actually brand new.
In fact, James Bach has written that the practice of test automation predates even the concept of “dedicated software testers”:
Test automation is not at all new. What’s comparatively new is the idea of a tester. Long ago, in the late 40’s, dedicated testers were almost unknown. Programmers tested software. Throughout the sixties, papers about testing, such as the proceedings of the IFIPS conferences, almost always assumed that programmers tested the software they built. Testing was often not distinguished from debugging. As larger and more complex systems arose, the idea of dedicated software testers came into vogue.
Thinking in extremes
And yet even though test automation itself isn’t new, it has become quite a hot topic very recently (possibly bolstered by the continuing spread of development methodologies and strategies like Agile and ATDD/TDD).
The conversation is dramatically polarized. Those at one extreme vehemently oppose automation, seeing it as a death sentence to good ol’ fashioned manual testing, human testers, and even software testing in general. Those at the other extreme blindly champion automated testing, dismissing exploratory testing as “playing around.”
This “Us vs. Them” view is producing a mentality that says automated and manual testing are at irreconcilable odds with one another, that they can’t get along, that you can only use one or the other. And that’s a shame, because “or” sure is limiting.
“And” instead of “or”
So instead of “or,” if you really care about your application’s quality and integrity, I urge you to consider “and.”
Don’t settle for using only one method of testing. Using both automated and manual testing allows you to reap the benefits of both techniques while mitigating the shortcomings of using only one or the other.
Here are two examples:
- Automated testing can help you speed up testing cycles, test constantly, and test more consistently, but at the end of the day, an automated script can only check what you tell it to check. Testing faster is good, but testing less thoroughly is bad.
- Manual testing – particularly exploratory testing – can unveil lots of problems, from user experience issues to serious bugs that no one even considered, but doing it well takes a long time and all of the tester’s attention. When you have to do everything by hand, you simply can’t do as much.
Manual testing and automated testing don’t diminish one another; they enhance one another.
Making it work for you
Whether your company currently is purely an automation shop or relies solely on manual testing, you can make this magical testing combination work for you.
Introducing manual testing
If your team has been neglecting manual testing, believing that your automated tests provide all the coverage you need, think again.
Re-evaluate your automated suite to make sure that your automated tests are as robust as possible and that they’re truly exercising your application. Likewise, review the results of automated test runs with a critical eye. Remember that a 100% pass rate doesn’t necessarily mean your site is bug-free; it could mean that your automated tests aren’t well-written or aren’t doing what you think they’re doing. Then update your automated scripts as needed to get them in the best condition possible.
Once you’re confident that your suite is up to date, it’s time to turn to manual testing. Assign test cases that aren’t suited to automated testing to your test team for manual scripted testing, and be sure to give your testers time for exploratory testing. Doing so may involve a shift in priorities and testing schedules, and that’s OK.
The important thing is that by bringing manual testing into the mix, you’ll be able to cover your application’s functionality even more thoroughly.
Introducing automated testing
On the other hand, if your team has been using only manual testing, add automated testing into the mix.
To start, you’ll need to select an automated test tool that suits your application and the testers (or developers) who will be creating your automated test scripts. There are lots and lots of tools out there, and choosing the right one can be difficult. Software testing tool review lists like uTest’s list of highest rated tools can be a great resource on your search.
Once you’ve selected your tool and figured out who will be responsible for creating the automated tests, you’ll need to make sure those team members have time to script. Obviously building out your automated suite won’t happen overnight, but by resolving to create a few automated scripts each sprint or release, you’ll gradually get there.
And once those automated scripts are running regularly, you’ll be amazed at how automated testing can relieve some of your team members’ burdens and how much more of your application you can test each cycle.
Stop thinking in terms of “or.” Use both manual and automated testing to make sure your application is in tip-top shape.