By David Zinman
To expedite development and quality assurance cycles, many software projects incorporate automated testing. Automation of testing can greatly reduce phase times and reduce costs for the any outsourced or internal project. By analyzing the way test automation is done, Mapleworks has developed a solution called Mapleworks Automated Testing System or MATS.
What is required from a test automation system?
- The ability to run different types of tests:
- Unit testing
- Full system testing
- Integration testing
- Regression testing
- Performance testing
- Consistency and reliability
- Observable detailed results with comparison ability
- Flexibility – test and test suites
At Mapleworks we’ve found some practical problems with test automation. Take the case of a long and involved test script. These types of scripts can be recorded by a test platform or created manually with a sustained effort. If an essential piece of functionality has to be modified, then the script must be re-recorded or re-factored in some way. And say this modification is applicable to several different places in the delivery, the cost rises exponentially to the quality assurance cycles.
At Mapleworks, we have designed a novel approach to solving this problem. Using the TestComplete platform, we have added an abstraction layer that takes an arbitrary label and points it to each testable object. This de-couples the test script and testing engine from the tested program.
What we can now do is record an intricate test procedure, convert it to a MATS (Mapleworks Automation Test System) script and create the mapping file for the testable components.
An added benefit from this architecture is that the QA team can write tests before the project is completed. All that is required to run testing suites is the mapping file to be filled in with the actual component internal name which can be obtained using the TestComplete ‘map object from screen’ tool.
The mapping syntax is straightforward: an arbitrary descriptive name, its object type (button, list, etc), and its component internal name which is implementation specific.
Sample Component Definition File:
Template Editor|Catalogs, Tab,.WinFormsObject(’WindowDockingArea’, ”, 3).Pane.Panes.item[1]
Template Editor|Catalogs|=Catalogs|,Copy,WinFormsObject(’TemplateEditorFramework’). WinFormsObject(’splitContainer1′).WinFormsObject(’SplitterPanel’, ”, 1).WinFormsObject(’Navigation’). WinFormsObject(’CatalogTab’).WinFormsObject(’CatalogFramework’).WinFormsObject(’tableLayoutPanel11′)=WinFormsObject(’FormFramework’).WinFormsObject(’mainContent’).WinFormsObject(’caiTableLayoutPanel1′).WinFOrmsObject(’panel’).WinFormsObject(’CatalogFramework’).WinFormsObject(’tableLayoutPanel11′)
Template Editor|Firewall and QoS|Port Triggering|Table|Service,Table, WinFormsObject(’TemplateEditorFramework’).WinFormsObject(’splitContainer1′).WinFormsObject(’SplitterPanel’, ”, 2). WinFormsObject(’ContentPanel’).WinFormsObject(’PortTriggering’).WinFormsObject(’panel1′).WinFormsObject(’ports’).WinFormsObject(’Port’, ”, %row%+3)
The test script has a similar syntax: the arbitrary descriptive name, an action, and any optional parameters.
Sample Test:
Test=Set Service in Port Trigger to ‘aci’ using drag and drop
Template Editor|Catalogs,Click Template Editor|Catalogs|Services|Tree|TCP,Click
Template Editor|Catalogs|Services|Tree|TCP|,Find,aci
Template Editor|Catalogs|Services|Tree|TCP|%currentEntry%,Click
Template Editor|Catalogs|Services|Tree|TCP|%currentEntry%,Drag, Template Editor|Firewall and QoS|Port Triggering|Table|0|Service
Mats simplifies testing since creating tests does not require programming just simple scripting, the tests are flexible to most application changes, and developers only need modify the script to update, create, and run tests that support changed functionality/implementation.
What can be tested?
- Files
- dBs (via ADO)
- Native Windows applications
- Web applications
- Visual properties of controls (fonts, colors etc.)
- Input/output text (variable text such as user names and fixed text such as prompts for multi-lingual applications)
Here is what the architecture looks like:
Notice that TestComplete is not required to run the tests, the much cheaper TestExecute is all that is needed. At least one instance of TestComplete is required however to record any scripts.
Benefits
There are several advantages that MATS gives to the testing procedure. The use of arbitrary component names permit implementation to be changed without changing tests. Tests are easier to create since they can be written by testers in simple script before the application is available. Testing can easily be performed by developers before committing changes. This assures addition problems are not introduced.
What started as a convenient and cost effective way for an us to offer a value added service has become a product in its own right. We have found customers who are interested in adding this novel approach to automated testing to their QA procedures as a way to cut costs, and expedite testing cycles.
