The automation of testing software is being adopted more and more frequently by businesses, meaning many are becoming more dependent on it. However, few businesses and software engineers are able to maximise the full benefits of test automation, and there are consistent errors that are made. Here are some common mistakes, and how you can solve them:
Use playback scripts
A lot of automation testers use record and back to create test scripts, but this should very rarely be used as the last element of making a script. Effective automation needs the customisation of the generated script – the record feature is a way only to make the bones of a script, rather than relying on it.
Solution: To customise a script, you need to look into data parameterisation, and add checkpoints to validate. A good tip is to break the script down into modules, so that several testers can work on it at one time.
Copy and pasting test code
Writing the code is unavoidable, even if your record and back tool appears to be codeless. It’s a task few people enjoy, and so they are likely to want it to be over and done with as soon as possible, rather than focusing on doing the coding well. This will usually involve creating a function that can be reused, and then just copying and pasting, altering it slightly to fit a new function. It is only when you wish to change how the code works that problems arise! You could spend days trying to search and replace code, which is expensive and tedious.
Solution: Make sure that functions are properly created for logical processes. The page objects structure helps you do this in an intuitive manner.
Overlooking validation
Up there with some of the most common mistakes that test engineers make is the failure to use proper validation on scripts – if they use any at all. Not using validation, for example, on a login page, can be problematic for testing, and showing that the process has been completed. Some enterprises only using visible means of validation, but this, too, is restrictive.
Solution: Consider using checkpoints that help to detect web objects, or text on the page, to make it easier to see if the process has been completed.
Keep testing separate
A less obvious problem is that problems don’t occur unless the entire system is in operation; to create a test, someone must make a note of all the actions along the way of things that don’t work. Once the errors have been ironed out and you get the first clean test run, it only really has value after something stops working. By keeping adding test runs onto the end, and not deleting code that doesn’t do what it was meant to do anymore, it creates a back and forth, and adds demand onto a system that only exists because it failed in the first place.
Solution: Begin with examples that can be run by a software system or person, and get someone to teach employees about what they need to do to make it successful, with the minimum amount of work, and make tools part of the requirement.
Thinking of testing as a standalone programme
Code very quickly grows to be a complex, huge mass, and it becomes almost impossible to distinguish between it when trying to debug. When trying to look for errors without clear definition, it can be like looking blind.
Solution: If you look at it more like a spreadsheet, with clear, defined separation, the amount of time (and mental energy) you could save is immense. Try organising in different ways to see what suits you best.
Ignoring the pipeline structure
Testing doesn’t just entail executing and reporting what the test flags up. There is much more involved, such as test design, strategy, test data, environment set up, which all have an impact on the testing process. By ignoring this structure, you are actually only automating a fraction of testing process, and creating a drain on your human resources.
Solution: Create a base check that runs from end-to-end to begin with, and build on that by adding additional scripts slowly and carefully, to automate in sections.
Done properly, software testing automation can save you an untold amount of time, but it is not an easy process and should not be rushed. By taking your time and building up the automation process slowly, you could see something that was previously a drain on human resources become something that requires far less man power than you ever thought!
