I run across a lot of testing organizations that haven’t yet made the leap to automated testing.
There are a lot of misconceptions about test automation and there are many things that these folks are unknowingly missing by not taking that step.
If you’re one of them, please read on.
Common misconceptions about test automation:
- It takes too long to develop automated tests
- Automated testing is more expensive – I’d have to engage offshore testers or hire software engineers with a certain skill-set to do it
- Test Automation tools are “snake oil” – they never work as advertised
- Automated tests are very labor-intensive to maintain or keep up-to-date
In fact, none of these things are true! You can implement automated tests without having to go offshore or hire expensive people with highly-specialized skills, and you don’t have to spend a fortune on maintenance. There are tools out there that are relatively easy to use and don’t require any more planning and design than what you’re already doing for manual testing.
>>Furthermore, you are putting your business at risk
if you are not automating.<<
What are you missing?
Automated tests can be developed quickly and easily.
Using the right test automation framework allows any user to develop automated tests without scripting, programming, or excessive heavy-lifting. What’s more is that you can reuse the automated tests over and over. It’s easy to deconstruct them for use during new, future development, or you can add them to a growing regression test pool.
For new feature testing, you need to string together the tests you’ve already run into an end-to-end business flow, connecting the pieces of the product together. Essentially, you have to build on those test cases that you already have. If the base tests weren’t already automated, then you’re re-running those tests again manually, once again adding time to your test cycle and delaying the delivery of your product.
Automated tests are cheaper.
Automation frees up a large number of resources that manual testing consumes. This includes business analysts or your system users for several weeks, or even months depending on the size of your system changes. Shouldn’t your business users be spending their time on quarter-end activities? Or developing new requirements? Why should they be stuck running the tests over and over? Sure they should be involved, but they don’t have to carry the load release after release.
Using offshore resources could put your business at risk.
Why would you outsource the testing of your critical business processes with an offshore group who doesn’t understand your business? Test automation tools can and should put test design into the hands of the people who know your business processes and work with the business risks every day. Period. Very few offshore groups I run across have that level of insight, or it takes years and years to develop.
Manual tests are subject to human nature.
None of us like to have to do the same task over and over and over and over. Once a test has been run once or twice, it is human nature to cut corners and the test is never run twice the same way and important things are missed, even if the test steps are very carefully written down. More often than not, the test steps are not written and it’s up to the tester to interpret what the test is supposed to do and what the expected outcome is supposed to be. And if there is turnover in the group, good luck finding someone else who knows what they’re supposed to do and how. Having repeatable tests that are run exactly the same way every time, no matter how many times you run it is extremely important, especially if those tests are covering a critical path in your business process.
Make sure your bugs are fixed.
During testing, it is inevitable that you find bugs – that’s the point! If you’re not finding bugs, you’re not doing it right. So, when the bugs are fixed, you need to retest. And every QA engineer knows that you are most likely to find bugs where you’ve already found them. When a Developer is fixing a bug, it wasn’t part of the original design. He’s more than likely making a “quick fix”, and most Developers don’t even have their fixes reviewed by other Developers. So you actually need to test more in that specific area of code than you did to find the bug in the first place. Testing more means adding additional boundary conditions and negative tests so that you are sure that the fix didn’t cause more damage. Plus you need to run the regression tests. Every time you cycle through that test->find->fix->retest loop you’re testing more, not less. Pretty soon, your manual test cycles are growing, sometimes exponentially. Do you have time for that?
Continuous testing is needed more often than you think.
If you’re like most QA organizations, you’re continuously having to retest. How many patches or updates do you get on you application? What happens when you also need to integrate new functionality into the release? Having automated tests is imperative for continuous delivery, continuous release, and all patches and updates.
With the right test tool, such as cFactory, maintaining tests should be seamless – the tool should do all the “heavy lifting” for you. It’s true that you have to know the areas that your application updates are impacting; however once you know that, cFactory can make those updates for you in a small fraction of the time it would traditional automation groups who are refactoring the automation. This keeps your automation fresh for every sprint, release or regression cycle.
It’s easy to get caught up in the myths and misconceptions. And it’s easy to keep doing it the way “it’s always been done.” But I ask you, can you really afford not to automate?
Tell me about your experiences with automation in the comments. I’m listening.