BUSTING TOP 4 MYTHS ABOUT TEST AUTOMATION
If you are thinking about using Test Automation for your projects, then you will not allow yourself to believe in Myths about it! And that’s why today we are BUSTING THESE MYTHS!
Myth №1: Anyone can write a script. Really?!
The right tools can simplify automated testing, but they won’t do everything for you. Most often, such utilities help to write down a script or sequence of actions and, as a result, repeat them. Therefore, they can not do everything for a person without experience testing or development.
Even a simple test will require a certain level of skills to automate the use of variable values, monitor the success of each step, and so on. And more sophisticated checks have their own nuances, which are unlikely to be done by an inexperienced tester.
Experienced professionals are much better controlled with complex scripts that do little more than throwing a user around the corners of the interface. You would definitely be disappointed if the person testing manually did not recheck the output data. In the same way, you should be disappointed by the scripts that ignore the test results.
Myth №2: The script is written and the magic begins. Run through all versions of the build!
Eh, it would be great if it were that easy! In the real world, we analyze the output of the script and edit it to keep up with changes in the system under test. The more scripts you have, the more things you should take care of.
Yes, you can continue to run the same tests for new builds, if the product does not change dramatically, and just make edits to the scripts. But if the project has such a strength functionality, then you are unlikely to get something from reusable automated testing (in particular, if you don’t set a goal to test performance, resistance to stress). Constant analysis of the unchanged software as a whole does not make much sense, both in auto and manual testing.
On the other hand, if the user interface is constantly changing, you will often need to edit the scripts. In this case, manual testing will take less time than you spend on digging into the scripts. However, the more time autotests are in the outdated state, the more difficult it is to bring them back to life in each subsequent build.
Myth №3: Why do we need something else when there is Test Automation?
It is impossible to replace other types of analysis with autotests because a human perspective is needed to evaluate the results of the test. A script can not make a final decision for you.
For example, you check the form to create a user account. Write a script that will fill in the fields with data, send a form and check if a new account appears with the selected information. The cycle is over, the results of all are satisfied, there are no problems.
Since you have a quality assurance team in your team, someone eventually checks the form manually. QA-engineer enters the same information, “accounting” is created and everything is fine up to this point. But the tester has eyes, and he sees that the background image is not displayed, the imposition of the form is broken or the function of prompts does not work. Based on an automated test without human control, such annoying defects can be missed.
Myth №4: I wrote the script once and it’s enough!
Unfortunately, the once written script cannot be used constantly.
Even a simple dialog box added in the new version can overwhelm the automated check. A living person will easily perform the test in the update, and the script will have to be updated so that it passes the new condition.
And if you have a bunch of simple scripts to turn the interface back and forth, then after making changes, each script may require editing. Do we need it? Even if you take the time to create flexible modular scripts, after modifying the processes or rules, you will have to refine them. And the time that could be spent on testing the changes, merges into finding the necessary scripts and rewriting them.
If you analyze client-server and want to add multi-user testing, the situation becomes an order of magnitude more complicated. Now the scripts relating to the user should be able to transmit information about the changes to each other. Thus, we see that testing automation is also the effort required to support autotests, caused by product development.
We at Fintegro Company Inc. love automation, this is a cool and necessary thing. But everything must be approached wisely. And the main thing is an integrated approach in the application of manual and automated tests. Automated testing brings results when the interface is already stable, and the core code is still changing and improving.
You are welcome to read more articles about Test Automation in our blog!
“What to automate? What not to automate?”
Feel free to contact us and do not forget to follow us in social media:
LinkedIn: https://www.linkedin.com/company/fintegro-company-inc
Twitter: https://twitter.com/fintegro
Facebook: https://www.facebook.com/fintegro
P.S. We are always happy to read your comments and thoughts ;)
