cFactoryTM is a script-less automation tool which works on top of HP UF. The automation developer need not use UFT anymore to develop the scripts; instead they can use cFactory to identify all the objects in the application at once. Against each identified object, the automation engineer can just select the available operations which match the test case steps and save the script (component). Once the components are created, they then are synced into the ALM business components repository for re-usability.
cFactory’s dataDriverTM is used for data driven testing of automated test cases. The ALM uploaded business components are assembled in the correct order to complete the automation – such as Sales Order Creation, where cFactory is used to create components.
1. Login to Apps
2. Navigate to Sales Order Form
3. Enter SO Header
4. Enter SO line
5. Book Order
6. Verification of Order No
The test case is created by stitching the above business components. Each component takes variables and is created as parameters in the component automatically by cFactory. Both input and Output parameters are available. The dataDrivers can be used to create an excel file which automatically creates the flow excel file with all these input/ output parameters.
The scenario number determines what data to use – and with the help of the datasheets the same test case can be run for multiple data sets.
cFactory automation framework helps to enter only the required data by giving the values in the dataDriver files, and the remaining fields will be ignored automatically. Ex: If the value for Password is not given in dataDriver, the tool skips it and continues with the next step.
General way of doing Automation
Using cFactory
Automated components can easily be upgraded with the application changes (version or UI). The automation engineer can use the cFactory tool to capture the application objects with single click for new components, while the tool automatically compares both new and old objects and lists all the differences, which makes it easy for the QA engineers to modify the scripts.
This blog post was written by our testing consultants Rajasekhar Nanduru, Sai Prabha, and Manasa Mothe.