Customer Guest Blog
Giri Prasad Palanivel
“Programmatically developing an automated test consumes more time than the record and playback method.” This is the general opinion held by many QA engineers. It's also the first major decision that needs to be made when implementing test automation for a given project.
If we design our automation framework with future application under test (AUT) enhancements in mind, select a tool that fits our needs and take full advantage of that tool's capabilities, we can completely reap the benefits of test automation. More importantly, the initial time spent developing tests programmatically will be recouped over the development lifecycle.
To design a good automation framework we need to understand the AUT and its behavior. Keep in mind that a framework that worked for one particular project may not be a good fit in another project. So let me list few points to consider while designing your framework.
- Separate your data from your tests.
- Build a library of common functions to aid in code reuse.
- Have test data/expected data in a format which is widely supported in and out of the selected automation tool selected.
- Try to have the framework independent of the tool/language.
- Accommodate exception handling and recovery scenarios.
Now let's shift our focus to the next important factor – taking advantage of an automated testing tool's capabilities. Let's go through what TestComplete provides and how it helps rapidly automate test cases/scenarios.
While you're performing a manual test case, TestComplete can record your actions into a test script. This gives you good insight into how TestComplete can work with your application.
Once you've finished recording, go back to your recorded scripts and examine the code. Look for places where you can modify it per your framework design. Ask questions like:
- Which part of the code can be reused/modularized/parameterized?
- How to best organize your code across suite/project/modules?
- How tested objects are to be stored in ‘NameMapping’
- Decide ‘TestedApps’ launch properties.
A Note on Web Testing:
If you're testing a web application, then you need to decide how TestComplete will identify and display controls. Ultimately you have to decide on the web page ‘Tree Model.’ TestComplete supports four types of tree models – DOM, Tag, Hybrid and Tree. The answer for this depends on your application/product page structure. For example, if your application has few controls within a small hierarchy of parent controls, then you may wish to go with DOM or Tree. If your application has many controls/objects embedded inside a large hierarchy of objects, you may want to use the ‘Tag’ model over others. TestComplete provides you the flexibility to choose your preferred approach.
Choosing the correct Tree Model can make or break your test development efforts. If you don't determine the appropriate choice early on, and then realize you need to change it, your previously developed scripts may need a lot of rework.
Object Recognition and Mapping:
While automating, we need to deal with different objects holding different properties. We might come across a few objects which are not readily recognized. In that case we may need to consider the following workarounds:
- Try for a regular expression/wildcards in properties to identify the object.
- Have a combination of properties of an object/control to identify it uniquely.
- Relatively identify the objects – as Parent, Child and positional constraints etc.
Using a feature called Conditional Mapping, we can map our objects based on conditions specified with ‘AND’ & ‘OR’ constructs. You can switch between basic to conditional mapping in the “Object name mapping window.” This option allows you to specify several criteria that can be used to reliably identify an object at test runtime.
Handling test data:
An ideal test automation framework will separate its test data from the tests themselves.
Using TestComplete's built in DDT object we can quickly connect a test to an external data source and manipulate the test data inside our scripts. The DDT object is supported across all of TestComplete's scripting languages. This feature enables us to develop driver scripts that take advantage of data storages like MS Excel, CSV, and ADO based databases.
For keyword-driven tests, TestComplete provides a ‘Data-Driven loop’ wizard which helps us easily connect tests to a data source.
As we discussed earlier, we have multiple options to store our reusable/common functions. If you have common functions which are used across multiple scripts and multiple projects, the best option is to use Script Extensions. Extensions enable us to reuse existing code and decreases the amount of time needed to develop new tests.
In some cases, you may find yourself retyping the same handful of code statements in many of your tests. Let's say you have a customized way of handling exceptions and this same code is to be embedded into each function/module. To speed the script writing process up, put the customized code in a ‘Code Template’ and use it wherever you need it. ‘Code Templates’ can be found at Tools -> Option -> Panels folder -> Code Templates.
Just add your code (template) to this option and use them by entering keys CTRL + J to get the list of available templates and select your template to be populated inside the code editor.
The files, objects and regions required for executing our scripts and for verification can be linked to the project using a project item called Stores. Stores can hold tables, files, Objects (as XML), Regions (as images) and XML files. TestComplete has built-in methods to access the stored items directly and use them in our scripts. If we have baseline files/objects/regions stored in this item, TestComplete has options to update them automatically when the baseline needs to be changed. This reduces the time needed to maintain the files used in our testing.
Using TestComplete's ‘Code Explorer’ panel, you can improve the quality of your scripts. This panel allows us to review our developed code based on the configurations specified in it. You can change your configuration specified in it to suit your framework needs.
Finally, if you need clarifications or if you get stuck, you can contact SmarBear's support team in a variety of ways, including via their blog, forums and online chat. Alternatively you can email them your problem directly for a quick response.
I am sure there are lots of other important factors which decide the outcome of test automation. Please feel free to share them.
My blog: Believe!!! There are 101 ways to automate...
Thanks & Regards,