If you’ve been manually testing your websites for any amount of time, you are already familiar with many of manual testing’s drawbacks. Even for small sites, it is time-consuming, the process is prone to errors, and it’s nearly impossible to cover every scenario. On top of this, it is extremely repetitive. There is an inverse relationship between the degree of tedium and quality in a manual test. Humans are just not very good at paying attention to boring details. There’s a strong tendency for those writing boring tests to lean towards the “test and done” mentality, meaning they don’t revisit the test after writing it. This can increase the likelihood of missing unexpected problems.
Manual processes also prohibit the effectiveness of doing regression testing. Add that to the fact that without a massive team of testers, all doing the same thing at the same time from multiple locations, load testing is impossible.
Transitioning to automated testing reduces QA time, speeds up product delivery and drastically increases test coverage. The advantages carry beyond the process itself: the more bugs you catch in pre-production, the less maintenance time is needed later down the road. Plus, if you spend less time writing repetitive tests, you’re freed up to do less boring, more value-adding work.
But the question remains: how do you make the transition?
There are several factors that can get in the way of migrating from manual to automated testing. Let’s address these:
The first thing you should do before migrating is to create a foundation for what testing will be automated. Typically, you will first be working with a hybrid system – some aspects of the testing process will be automated, while others will remain manual.
Spend some time evaluating different options, and identify which ones will work best by considering factors mentioned above in the obstacles. Does your team have the skills needed to handle a full framework? Can you get by with a few libraries? Does your team want to invest in an automated testing tool? With a good automated testing setup, it should be possible for your team to expand their existing methods onto a larger scale, where changes can still be tweaked.
Compare each of these setups against your infrastructure, and consult with all shareholders (testers, designers, developers, operations, etc) before making a choice.
The first stage will involve doing what you’ve always done – mapping out your procedures for manual testing.
Run through your tests and identify steps which are repetitive. Create small scripts that encode these. As you migrate from a manual to automated testing process, you will be creating a script identifying your pre-existing procedures.
It’s important to remember that the more complex a site is, the more scenarios need to be tested. Identify each aspect of an application that should be tested. Identify which items should be tested more than once. Assume that something will go wrong with each one of them. Analyze which steps need to be made if a user gets an error. Take your simple tests and include them in scripts which can be reused for regression testing purposes.
When everything is working smoothly for individual tests, slowly implement automation throughout your entire DevOps process. Testing any stage where problems can be caught (e.g. within a build) is a great place to improve the entire process.
It’s important to remember, especially when developing automated tests, that at some level, manual processes have to remain. These areas include:
Remember to put faith in your users when it comes to testing whether a site will be effective. Manual testing allows you to identify usability issues and very specific bugs that can only be surfaced by the erratic nature of human behavior.
There are other places where and reasons why automation does not always make sense. Most manual testing doesn’t require any specialized skills, and it’s actually usually best if non-experts do the initial testing. The unpredictability of human behavior is incredibly valuable for finding bugs.
Remember, when migrating to automated testing, walk before running. Run before biking. Bike before hopping on a motorcycle. And don’t forget to use existing roads. But most importantly, remember that mabl’s here to help you on your team’s path to time-saving, powerful test automation.