Test Management Blog

Tracking Results and Traceability for Automated Tests

December 12th, 2014 by Bill Echlin

You’ve configured your test hosts (Bringing Manual and Automated Tests Together) and you’ve set up and run automated tests from QAComplete (Setting Up Automated Tests in QAComplete). Now we’re running these automated tests how do we track the results and how do we follow the traceability back to our requirements?


For many of our automated tests we’ll want to track traceability back to the requirements they are providing us with test coverage on. From an QAComplete implementation point of view automated test cases are no different to manual test cases. Automated test cases are defined in QAComplete and linked back to the requirement. This traceability can be seen and modified when you view the test case in the test library.

Automated Test Cases with Requirements Traceability in QAComplete

Once we have this traceability setup the automated test can be run as part of a test set and a test run record created. In this next section, Run History, we talk about tracking the run history and then in the Dashboards section we look at how to create traceability reports.

Run History

So each test set run (which may or may not contain automated test cases) has a result set stored in the run history record. This can be found here:

Test Run History in QAComplete

You can search through and group the run records with the ‘Group By’ and Quick Search features. Bear in mind that you can’t filter on execution type and see just the automated tests. This is because each test run relates to a test set that can have multiple test cases included in it. Multiple test cases in a test run can be a mix of automated and manual tests.

You can check the test type (either manual or automated) by drilling down into the individual tests themselves. To do this view the test runs and then open up the run view, followed by the review test view. In the test view, under the status info section, you’ll see the execution type.

Test Run type in QAComplete

To start looking at test runs that focus specifically on automated tests we’ll need to create filters and look at some of our test dashboards.


If you want to see test run results related to other artifacts (like requirements) you can view the “Test Runs by Requirement” dashboard. This shows the individual test case results per requirement.

Test Runs by Requirement Dashboard in QAComplete

In this example three test cases have been executed (across one or more test sets) where all three test cases have been linked to the requirement. The test results shown here will be combined results from both the manual and automated tests that have been executed (not forgetting that test sets can contain both manual and automated tests).

In another example you can see the Test Runs by Configuration dashboard. As long as the test set (that contains the automated tests) is linked to a configuration and the test set run is actually run on that configuration then the run results will show up on the ‘Test Runs by Configuration’ dashboard. It worth pointing out that this dashboard view doesn’t list individual hosts just the type of host configuration that the test set was linked to.

Test Runs by Configuration Dashboard in QAComplete

If you are looking to report on just test cases that are automated then the best approach is to create a filter. Create a filter that based on the field ‘automated’ and set the condition to ‘true’.

Test Library Filter in QAComplete

Test Library Filter Creation in QAComplete

With a filter setup up you can now view the dashboards and apply the filter. For example this ‘Test Library’ dashboard shows the last run status for tests but has the ‘Automated’ filter applied. So the result is the display of last run status only for automated test cases.

Tests by Last Run Status in QAComplete

Segregating Automated and Manual Tests

QAComplete lets you mix automated and manual tests in any way you like. This flexibility can be good, if for example, your focus is requirements coverage. If you are focusing on requirements coverage and all you want to see is test results (whether they are automated or manual) then mixing these different test types in Test Sets that are requirements focused is the way to go. So for example you create a Test Set containing manual and automated tests that cover one particular requirement.

For some QA teams though there’s a need to keep manual and automated tests separate. Perhaps your automated tests are run just to cover the regression aspects of your testing. In which case you may not be so worried about tracking the requirements coverage. So you’d take a slightly different approach to setting up QAComplete in this case.

If you want to keep your automated tests separate then you need to approach the construction of your test sets in such a way that a test set only contains automated tests. The best way to do this is as follows.

First, in the Test Library, you need to identify test cases that are automated. Here again we can use the ‘Automated’ flag that signifies if a test case is automated. Add the ‘Automated’ flag to the list of fields displayed.

Choose List of Fields in QAComplete

Then make sure you have the ‘Automated’ flag selected.

Choose List of Fields Dialogue in QAComplete

This will help you identify the automated test cases from the manual test cases.

List of Automated Tests in QAComplete

Using this in conjunction with a filter setup with the ‘Automated tests flag’ and you can pull out the specific automated test cases you need to create a dedicated automated test set. Once you have those test cases listed use the ‘Create Test Set’ button.

Create Automated Test Set in QAComplete

The key here is to make sure you create a folder structure for your Test Sets that allows you to separate out automated and manual test sets. Also make sure that you have a naming convention for your test sets that identifies the test set as an automation set (the reasons for this will become clear in a minute).

Name and Location for Test Set in QAComplete

Then when you create test sets that only contain automated tests you make sure you store those test sets in the ‘Automated Test Sets’ folder. Also make sure that the title/name for the ‘Automated Test Sets’ contains a string like ‘AUTO:’.

When setup like this we’re in a position to filter our test runs and dashboards based on this folder and/or title string criteria. For example if you now view the Run History you can create a filter that pulls out only the Test Runs for Test Sets where the name contains ‘AUTO’.

Test Set Filter in QAComplete

If you then group by ‘Date Started’ and apply your ‘Automation Runs’ filter you’ll see all your automation runs filtered and grouped by the run dates.

Test Set Filter Applied in QAComplete


The ability to define automated and manual test cases in one test library location now gives QAComplete the ability to deliver full traceability from all test types back to requirements and other project artifacts. This then gives you the ability to report on test coverage for both manual and automated tests in a consistent way.

As we’ll see in future posts this capability with TestComplete integration, the new Selenium integration (more on this soon) and ultimately integration with SoapUI/Ready!API makes QAComplete the hub of your test execution and reporting capabilities.

How To Map Objects in TestComplete – part 2

November 27th, 2014 by Bill Echlin

We’ve looked at ‘Why we need name mapping‘ and we’ve covered ‘What name mapping is‘. Now we’re going to take a look at the ‘How to map objects’ part of TestComplete.

The quick way to get started with mapping objects is to have TestComplete populate the name map as you record tests. This isn’t the best approach though. TestComplete does it’s best to create a concise list of mapped objects but it doesn’t always get it right.

The best way to build your name map is to map your objects manually. So switch off the automatic mapping (to stop TestComplete filling up the name map with stuff you’re not interested in). Then select all the objects you need to interact with and map them manually with names and paths that make sense to you.

1. Switch Off Automatic Name Mapping
Select “Tools -> Options” in TestComplete. Then from the options menu select ‘Name Mapping’ and un-check the ‘Map Object Names Automatically’ option.

Switch Name Mapping Off In TestComplete

Switching this off stops TestComplete creating lots of entries in the name map and aliases that confuse things. Even if you have lots of objects to map you may be tempted to use automatic mapping. I’d recommend you don’t do this. Use the ‘Map Child Objects’ feature which is more reliable (more on this later).

The whole point of this is to keep the name map clean, un-cluttered and well structured. This helps you see the objects you’re using in your tests and also helps you debug object identification issues much quicker.

2. Map Your Objects Manually but Automatically Select Properties
Open your application, each page (or screen) in turn and map all the objects you need to interact with. So for example open the web page https://www.zoho.com/crm/lp/login.html and then use the ‘Map Objects from Screen’ feature in TestComplete to map each object.

Map Object In TestComplete

Once you’ve identified the object click ‘OK’ and TestComplete will ask you to confirm if you want to use the ‘default identification properties’. You can answer ‘Map the object as …..’ to do this.

Map Object Automatically In TestComplete

This means that a best guess will be taken by TestComplete on the properties that will be used in future attempts to find this object. We’ll see how to change these properties later.

Alternatively you can ….

3. Map Your Objects Manually and Select Properties Manually
When you map objects manually you can select to chose a name and specify the properties used to identify the object. In this case you will need to select this option

Map Object and Properties Automatically In TestComplete

After we’ve selected this you’ll be presented with the dialogue box that allows you to define the object name and select the identification properties

Map Object and Properties Manually In TestComplete

4. Modify the Aliases to simplify the mapping
Whether you select the properties manually or automatically you should now see the mapped object entries entries in the Mapped Objects pane and the Aliases pane.

Map Object and Aliases Pane In TestComplete

At this point you can update the names in the Aliases so that they make more sense. So for example you might change the page name and panels names so that they have values you’ll understand in your test scripts.

Aliases Pane In TestComplete

5. Simplify Object Hierarchy
[Optionally] You can take this simplification a step further and remove any of the aliased objects in the hierarchy that you don’t need. To do this follow these steps…

i. drag the object you do need up the hierarchy tree (e.g. under the page object)

Drag Object Alias In TestComplete

So that you have this…

Drag Object Alias In TestComplete

ii. delete the objects you don’t need

Delete Object Alias In TestComplete

- select ‘yes’ when prompted about deletion

Confirm Delete Object Alias In TestComplete

- select ‘no’ when prompted about alias belonging to another item

Confirm Delete Object Alias In TestComplete

This leaves you with just the object(s) on the page that you want to interact with.

Final Object Alias List In TestComplete

And regardless of whether you are creating key word tests or scripted tests you can refer to your objects with neat meaningful names…


And as you map each object on the page you end up with really clean aliases list which makes it much simpler to reference objects in all of your test steps…

Final Object Alias List In TestComplete

6. Use These Aliases in Your Test Steps
From here you can use this concise list of aliases in your test steps as you create and build up your scripts…

Using Aliases in TestComplete

It may seem like a lot of work mapping objects manually. In fact it is a lot of work. However, it’ll save you so much time and effort in the long run if you get this right from the start.

Looking for help implementing a scalable and maintainable test automation solution? Talk to us about our Accelerator package. Download the Pdf brochure here

Setting Up Automated Tests in QAComplete

November 21st, 2014 by Bill Echlin

We’re going to continue with our look at how to combine manual and automated tests with QAComplete and TestComplete. We’ve already seen how to install and configure the Test Agent which connects QAComplete and TestComplete. Now we look at how to setup automated tests and execute them.

You will need to configure the Test Manager Agent on the TestComplete clients machines before you follow these steps. More on this in Bringing Manual and Automated Tests Together

Checking That Automation Hosts Are Available

At this point we should have the agent installed and running on the TestComplete client machine. This process should show in Task Manager on the TestComplete machine as

        TestManagerAgent     -      Test Manager Agent

You can also check in QAComplete that the TestComplete host is available by viewing the ‘Test Hosts’ records.

Show Hosts In QAComplete

Note that if the host isn’t listed at all you may need to enable the ‘Show Inactive Test Hosts’ option.

Show Active Hosts

If the host isn’t active then you’ll need to start the service on the TestComplete machine. On the TestComplete machine Press Ctrl+Shift+Esc to display task manager and then click on the ‘Services’ tab followed by the ‘Services’ button. In the Services window click on the ‘TestManager Agent’ service and start the service.

Starting the test agent for TestComplete

If you have a lot of virtual machines running TestComplete (along with the ‘TestManager Agent’) then this ‘Test Hosts’ view in QAComplete is a really useful view. It lets you to see which virtual machines are active and available for you to run your tests on.

Creating An Automate Test

Now that our Test Hosts are ready we can start to add automated tests to QAComplete and then execute those tests from QAComplete. This is a 4 stage process.

  1. Package up the TestComplete project suite
  2. Define the Automated Test in the QAComplete Test Library
  3. Execution of Automated Tests – standalone
  4. Exeuction of Automated Tests – as part of a Test Set

Package up the TestComplete Project Suite

Key to this step is packaging up the TestComplete project suite. Note that this works only at the project suite level. You can’t zip up just the projects. It must be the whole project suite. To zip the project suite up follow these steps:

i. make sure you’ve defined the ‘Test Items’ you need and enabled them within your TestComplete project(s).

Defining Test Items In TestComplete

ii. find the location of your TestComplete project suite on the file system of your test complete machine.

Project Suite Location In TestComplete

From here you’ll be able to see where TestComplete is storing the project on your file system.

Project Suite Location (2) In TestComplete

iii. On the file system (or in TestComplete) remove the log files. You may want to back these up or copy them to a different directory if you need to keep them. For the purpose of creating this zipped up project suite we don’t want Mb’s of log files which are of no use in the zipped project.

Delete Log Files In TestComplete

You will need to do this for all the projects in the project suite and the project suite log files.

iv. At the project suite level on the file system find the folder containing your project suite and zip up this project suite.

Zip up Project Suite In TestComplete

Note the name of the zip file (e.g. ProjectSuite2.zip) and remember where you’ve created this zip file.

Once we’ve zipped up the TestComplete project suite we’re in a position to create the automated test in QAComplete.

Define the Automated Test in the QAComplete Test Library

In this step we create the test case in the ‘Test Library’ area of QAComplete and then attach the zipped up TestComplete project suite to this test case.

v. First we need to create a new test. Navigate to the Test Management Library area in QAComplete and select ‘Add New’.

Add New Test Case in QAComplete

Then we need to define the usual meta data required to create the test case (e.g. Title, Description, etc). A couple of fields that are important though:

  • Execution Type: set this to Automated
  • Default Host Name: set this to the host that will be used by default to execute the automated test

Assuming you selected Execution Type = Automated then when you save the test case you’ll be taken to the ‘Automations’ tab for the test case. Here you’ll need to click ‘Add New’ to add a new TestComplete Project Suite.

Add New Automation in QAComplete

When adding a new TestComplete project suite to QAComplete you’ll be presented with the following 6 fields to complete:

  1. Title: either leave this blank and QAComplete will give this automated test the same name as the TestComplete project or define your own name
  2. Time Out: this is how long it should take to run the test. If it goes past this time out value then the test runner will stop running the test and move on to the next one.
  3. Entry Point: use this to identify a specific test or project to run. If you leave it blank the whole project suite will be run. Specify a specific test case to execute an individual test case or a specific project to run only one project.
  4. Agent: at the moment QAComplete only supports one type of test agent which is TestComplete/TestExecute. Other types of test agent are in the pipeline.
  5. Web Site Address or UNC Path: you can place the zipped up project suite file on a shared drive. In which case you’ll define the path to that location and the file name here. Alternatively…
  6. File Attachments: attached the zipped up project suite file to the QAComplete test case and upload the file to QAComplete

A completed record with a project suite zip file uploaded looks like this (the entry point in this example is at the Test Case level)…

Test Case Record in QAComplete

A completed record with a UNC path looks like this (The Entry point in this example is at the project level)…

Test Case Record (2) in QAComplete

At this point in time you can only add one automation project suite to a single QAComplete automated test case. In the future it should be possible to add multiple project suites to one test case. Each ‘automation’ instance then calling different test cases or projects within the project suite for execution. This is in the pipeline though.

Once we’ve defined the automated test in QAComplete we’re ready to execute the test, either as a standalone test or as part of a test set.

Standalone Execution of Automated Tests

To run the automated test case in isolation you click the run now button on the Test Case Library list view.

Running tests from the test library in QAComplete

If you don’t see the run now button then you’ll need to grant the neccessary security privileges in the Security Groups area under setup:

Setting Security Privileges in QAComplete

When running in Standalone mode you will be presented with this Test Runner window:

Standalone run mode in QAComplete

1. The ‘Run By Host’ setting will default to the ‘Default Host Name’ you define in the Test Case. If you want to change this you can click on the current run host name and you’ll see a drop down where you can change the host.

Before you run the test make sure that TestComplete/TestExecute is closed down on the host machine. If TestComplete/TestExecute is already running on the host machine the test run will fail.

2. Click the run button in the Test Runner window.

Not a lot appears to happen at this point in QAComplete but if you go to the run history area in QAComplete you’ll see a new run entry and the status of the run.

Run Status in QAComplete

If you have access to the TestComplete/TestExecute host you should see TestComplete/TestExecute start up and the test project suite run.

Exeuction of Automated Tests as part of a Test Set

At this point you may have a number of different automated test cases defined in the test library. We can group these into Test Sets and run all of these automated tests in one run.

One quick way to create a Test Set is to search for the test cases in the Test Library and then click ‘Create Test Set’.

Create Test Set in QAComplete

This gives you a new Test Set with your automated test cases already included in the Set. Give the new Test Set a name and enter any other meta data that’s important to you. Click submit.

Create Test Set (2) in QAComplete

Now when you go to the Test Set area in QAComplete you should be able to find your new Test Set and view the Test Cases included in the set.

Create Test Set (3) in QAComplete

Create Test Set (4) in QAComplete

You have two options at this point:

1. Run The Test Set Immediately

You can either run the test set immediately by clicking on the ‘Run Now’ button:

Run Test Set in QAComplete

In which case you’ll need to specify the release and configuration you want to run these automated tests on.

Select Release in QAComplete

Then select the hosts to run the tests on follow by ‘Run’.

Select Host in QAComplete

2. Setup a Test Schedule

The second option is to setup a test schedule.

Create Test Schedule in QAComplete

Where you define the Host Name you want the schedule to run on, Run days, Start time, End Time, etc.

Define Test Schedule in QAComplete

The important part here is the link to items. This is where you define the Test Sets and Test Cases that you want this schedule to execute.

Link to Test Items in QAComplete

Once you’ve defined the schedule you can leave it to QAComplete to kick off the automatoin runs on the required hosts at the defined times.

Don’t forget that TestComplete/TestExecute needs to be closed down on the host machines in order for the automated tests to run. It’s also worth pointing out that you can mix automated and manual test cases in a test set. If you do this then an automation run will only execute the automated test automatically (obvious really) and then you’ll have to go into the test run to run the manual tests yourself.

Next up, run history, traceability and reporting. We looked at how combining manual and automated tests in QAComplete helps you with traceability to other artifacts like requirements and reporting on combined execution runs.

Looking for help implementing a scalable and maintainable test automation solution? Talk to us about our Accelerator package. Download the Pdf brochure here

Bringing Manual and Automated Tests Together

November 7th, 2014 by Bill Echlin

Bringing manual and automated tests together to deliver combined reporting and traceability is an important goal for many QA teams. Usually this means linking an automated testing process into a manual test tracking tool. With the new 9.9 release of QAComplete and release 10.0 of TestComplete implementing an integrated solution becomes possible without investing vast amounts of money or lots of time and effort.

In this post we’ll be looking at how to setup QAComplete and TestComplete integration. Then we’ll see how this can really benefit your QA efforts as we look at combined reporting and traceability in the follow up post.

The high level architecture here revolves around having a central test management capability (delivered by QAComplete) and a distributed test automation capability (provided by multiple instances of TestComplete running on multiple hosts). The key being to install and configure a test agent on the TestComplete machines. These test agents then communicate with QAComplete to link both tools.

The first step in all of this is to setup these test agents on the TestComplete host machines. This is a 3 step process.

Step 1 – Setup a QAComplete User

From within QAComplete we need to setup a new user that will act as the account accepting all the automated test run results. This can be done from the Setup tab in QAComplete.

Adding a User In QAComplete

The important thing to remember here is that this user should be assigned to a ’security group’ that has privileges for the following areas:

  • Test Automations
  • Test Hosts
  • Test Schedules

This can be seen in this screen shot:

Security Admin Settings in QAComplete

Step 2 – Install the Test Agent

From your TestComplete machine login to QAComplete with a browser and download the TestAgent.

Downloading the Test Agent in QAComplete

When you run the Test Agent installer you’ll be guided through a few dialogue boxes covering warnings and licence information. Once you’re past these you’ll hit the dialogue box that covers the connection settings to QAComplete:

Connecting the Test Agent in QAComplete

If you’re running with the SaaS QAComplete service then you’ll need to enter the following Web service URL:

     SaaS Web service Url: https://qacomplete.smartbear.com/rest-api/service

If you’re running with your own On-premise install of QAComplete then your Web Service URL will be in the following format (clearly you’ll need to adjust this to point at your server)

     On-premise Web service Url: https://qacomplete./rest-api/service

To make sure that your TestComplete client machine has access to the server you can just take this URL and paste it into the address bar in a browser.


You should see a list of the Rest Opperations:

Rest Operations List in QAComplete

This proves that connectivity to the QAComplete server is okay.

Then enter the user and password that you created in Step 1. Note that the User should be the email address of the user you setup.

At this point when you click the next button the agent will attempt to check the connectivity and account that you’ve specified. If this succeeds you’ll get the next dialogue box that covers the windows account that the agent will use on this TestComplete host machine:

Windows User Account in QAComplete

In here you’ll need to add the domain, user name and password you use to log in to Windows and run TestComplete.

At this point the installer will configure and setup your new Test Agent. Once that’s finished your instalation should be complete and you’ll be presented with the completion dialogue box:

Agent Installed on TestComplete Machine

Step 3 – Check Hosts

If you log into QAComplete now, select ‘Test Management’ and then ‘Test Hosts’ you should see your TestComplete host listed.

Test Agent List in QAComplete

Now we’re ready to configure our host in QAComplete, setup TestComplete and start running our automated tests. We’ll cover this in the next post.

Looking for help implementing a scalable and maintainable test automation solution? Talk to us about our Accelerator package. Download the Pdf brochure here

Understanding TestComplete Name Mapping – part 1

March 28th, 2014 by Bill Echlin

Often when you start out with TestComplete you’ll find yourself bewildered by the complexity of identifying and naming the objects in the application you’re testing. TestComplete has a lot of powerful features to help with identifying objects in applications but when you’re starting out you’ll want to get to grips with the basics. The next few posts look at good approaches for mastering Name Mapping in TestComplete.

If you want to understand ‘why’ we have name mapping then this into article is a good place to start. If you want to understand ‘what’ name mapping is then read on. Or if you just want to find out ‘how’ to get started then we’ve got another post coming up soon.

What Is Name Mapping?

When we start out we’ve got a system that looks like this to TestComplete:

Test Complete Object Browser

What we need is a view or perspective on this that focuses on what we’re interested in for our tests. Something like this would be much easier to work with:

TestComplete Alias View

The Object browser

What’s in the Object Browser is exactly what TestComplete sees it at the system level. If you really wanted to you could even use the full system names to identify the objects in your tests. So for example if you use the object spy to identify an object you can see the full system name for the object.

You can then select the ‘Show in Object Browser’ button and you’ll see the object in the objects list in TestComplete. It’s this “Sys.*” name that you can then use in your test steps if you want to:

Sys.Browser("iexplore").Page("https://www.zoho.com/crm/lp/login.html").Panel(0).Frame("zohoiam").Table("outertable").Cell(1, 0).Panel("loginform").Form("login").Table("inntbl").Cell(0, 0).Table(0).Cell(2, 1).EmailInput("lid")

It’s not normally wise to use this though. The problem with the full system name is that it changes. It’s also difficult to understand because it’s so long. There are much better ways of identifying objects too.

Just bear in mind that this is where it all starts. It’s the foundation that the Name Map is built on. Think of the Object browser as the lowest layer. Then think of the TestComplete Name map and mapped objects as a layer on top of the Object Browser. When the Name Map is laid over the Object Browser it hides a lot of the chafe and complexity that you’re not interested in.

Mapped Objects

When you’re writing automated tests all you want to focus on are the objects in your application that you’re interacting with. So that you can focus on just the objects you’re interested in, the Name Map ‘Mapped Objects’ are picked out of system Object map. What you see then in a cut down list of mapped objects which are the objects you’re interested in for your testing.

So for example when you record a test, TestComplete will populate the name map with all the objects that you’ve interacted with during that recording. All the other objects on the system are ignored. Thus you get a clearer, more focused list of objects that you’re testing with.

That’s not to say TestComplete will give you a completely clear and focused list. TestComplete takes it’s best guess to identify the objects you interact with and map them. It’s not a mind reader though. It will map absolutely everything you interact with not just the objects you’re really interested in. TestComplete will also record the full paths to these objects which can be a little unwieldy. For example:


Not exactly easy to type if you have to refer to this object many times in your scripts. Having said that it’s a big improvement over the “Sys.*” object name. In fact TestComplete has taken some steps to reduce the complexity of the naming by removing some of the container references which helps a bit too (e.g. levels like Table(”inntbl”) have been removed).

Where does this leave us? Well we started out with this….

Sys.Browser("iexplore").Page("https://www.zoho.com/crm/lp/login.html").Panel(0).Frame("zohoiam").Table("outertable").Cell(1, 0).Panel("loginform").Form("login").Table("inntbl").Cell(0, 0).Table(0).Cell(7, 1).Button("submit_but")

And now we’re down to this…


Notice also that the reference starts out with the string “NameMapping.*”. Mapped objects start with “Sys.*”. The “NameMapping.*” naming convention can be used now in your scripts to identify that you’re refering to objects that are listed in the Name Map.

To make our lives even easier, and to avoid these long “Sys.*” and “NameMapping.*” naming conventions you can also make use of Aliases.


Aliases allow us to put another layer on top of the Object Map and the Name Map. So this final layer on top simplifies things even further.

This simplifies things for 3 reasons….

1. You can change the name of objects to make them more meaningful

So for example you can take the name “emailinputLid” that your developers used in the application and change it to “EmailTextBox”.

2. You can manually remove layers of the heirarchy/path to simplify the path name.

So for example you might have a long path in the Name map and then modify this in the aliases to shorten it to something more logical. So you’d go from …..




3. You can rename items in the hierarchy/path

So these parts of the path that are left still look a little unweidly. So we can manually go in and rename parts of the path. At this point we’ll take this..


and rename to give us


Far more readable and meaningful when used throughout out keyword and scripted test cases.


We’ve set out with a system name of….

Sys.Browser("iexplore").Page("https://www.zoho.com/crm/lp/login.html").Panel(0).Frame("zohoiam").Table("outertable").Cell(1, 0).Panel("loginform").Form("login").Table("inntbl").Cell(0, 0).Table(0).Cell(7, 1).emailinputLid

Then we’ve reduced it down with Name Mapping and Aliasing to end up with..


It’s not difficult to see just how much easier it will be to write and read our tests with the Alias naming convention rather than the full System naming convetion.

Up next: Using the name map properties pane to identify the objects reliably.

Copyright ©2014 - Traq Software Ltd - All Rights Reserved.