Tips to Achieve Testing Automation
In thousands of telecom provider and manufacturer testing labs, both management and engineers face the menacing task of testing and validating components and infrastructures by performing thousands of repetitive actions and procedures. The proper execution of these actions is essential to ensure the quality of the network and products under test.
Sadly, most of these procedures are not reusable; every change in an element or network layout requires manual retyping of the script. When the question of automating these processes arises, more often than not test teams avert the subject. And for good reason too. Skepticism is high regarding the possibility of creating user-friendly, cost-saving automated frameworks in even the most seasoned testing personnel due to problematic experiences in the past says Eitan Lavie, Vice President of product marketing at QualiSystems on lightwaveonline. These experiences may have been:
1. Self-developed automated systems that were so complicated that only the developing team could use them
2. Long automation projects that weren't worth the development time that was spent on them
3. The so called “automated" systems that relied on "capture and replay" scripting that required enormous effort for recording thousands of component-specific scripts.
So what must a manager or engineer do if he wants to effectively automate part of his test procedures? How can he overcome the common snags that cause automation to regress into manual labor and ultimate failure?
The way forward. The ideal approach to this problem does not lie in improving the current methods which is what most automation tool vendors and in-house projects attempt to do. Instead, the requirement calls for a new approach based on the creation of basic building blocks that are reused to create test automations. If we can create an infrastructure that allows test engineers to "drag and drop" actions into a logical flow chart and then operate these actions in the order they were placed, we could create an approach for cost-efficient automation.
But how can we achieve this?
Automation needs to be accessible to everyone, especially to the test engineers. Test engineers should be able to build the automation by themselves. If building the automation process requires code developers, the adoption rates will be low. If the time to create automation for testing a new feature is much greater than the time to test it manually, obviously something is wrong.
Reusability is important in automation. All the automated actions created should be contained within reusable building blocks from which the structure of the automation process can be built top-down. This means that once we've created automated testing for a certain network layout with certain components, changing a component or a small part of the layout should only require us to change a certain building block.
Every process should be standardized into one type of user interface. From a user’s perspective, the method of using the different types of building blocks described above should be the same in spite of the technology behind them being different. The fact that various communications are taking place "behind the scenes" should be totally irrelevant to the user – the user should need to learn just a single type of user interface.
So, all relevant test activities have to be supported within a single integrated platform. This includes topologies, devices, interfaces, procedures, tests, regressions, reports, and dashboards.
Data results need to be more comprehendible. One chief drawback of test automation is not the actual testing, but the lack of ease with which we can understand the results. Automation generates massive quantities of data, so it's important to understand how to turn this data into a beneficial test report.
Instead of manually parsing hundreds of files, we could easily aggregate information from multiple tests, testers and stations and then filter, group, and tabulate these results into a clear and coherent report.
Post your Comment
All form fields are required.