If you are testing your web application, it seems natural to test it with not only one, but with all of these most popular browsers (cross-browser testing).
This blog post will show you how to record your automated tests with one browser and automatically execute the recorded tests with the other ones. With Ranorex v3.2 (and higher versions) you can run your test in Internet Explorer, Mozilla Firefox, Google Chrome and Apple Safari.

Run one Ranorex Test Script in different Browser (Cross-Browser Testing)
Sample Test Suite ProjectTo demonstrate how to perform a multiple browser test, we will generate a small sample which enters data in our VIP Database Test Web Application, a small web application having the same functionality as the VIP Database you might know from our user guide.
First of all we’ll create a Test Case holding two Recordings, one for opening and one for closing the browser as setup and teardown modules.
Now we add a “OpenBrowser” action to the OpenBrowser Module with “http://www.ranorex.com/web-testing-examples/vip/” as Url and e.g. “IE” as browser.
As next step we add a recording module validating the status String on connecting and disconnecting.
The recording module simply
Make sure that the RanoreXPath of your App Folder does not include any browser specific equation like “browsername=…”.
Make also sure to have two repository items representing the connection status text, one for “Online” and one for “Offline”. This allows you to overcome issues with delaying validation steps. In our application it takes some time that the status text changes from “connecting…” to “Online”. To make the Validation work, we can simply add the actual validation into the RanoreXPath and only validate the existence of the status text in our web page. By doing so, we are using the search timeout of the repository item to wait for the status text to change.
Additionally to the TestConnection recording, we will generate a recording for adding VIP’s to the database. This recording will be added to a new Test Case as we want to data driven add VIP’s and do not want to open and close the browser and testing the connection with each iteration of adding a new VIP.
The recording might look something like this:
As we want to make our test data driven, we have to add variables which can be bound with the data from our data source.
The key sequences for first and last name contain the variables $FirstName and $LastName.
To select the category, we have to add a SetValue action and set the TagValue to the variable $Category.
The gender can be set by adding a variable to the RanoreXPath of the corresponding repository item.
Additionally, we validate the VIP count against a variable $VIP_Count.
After generating the recording, we create a data source for the Test Case Add_VIP’s and bind the data tables to the variables of the recording AddVIP.
As last step we add a Close Application action to the CloseBrowser Module with the application folder of the web application as repository item.
Now we can execute our Test Suite Project, which:
To perform these steps not only for IE but also for the other 3 browser which are supported, we first make the browser which will be started in the Recording “OpenBrowser” variable.
Therefore open the recording “OpenBrowser” and edit the browser which should be started. Now choose “As new Variable…” instead of “IE” and add a new Variable called BrowserName.
After that, add a new simple data table to the Test Case “Add_VIP_and_Validate”, holding the names of the different browsers and bind the data connector to the variable “BrowserName”.
After making the browser variable that way and binding this variable to a table holding all supported browser names, you can execute your test script for all supported browser.
It’s possible to manually perform all of your recording actions without pressing the record button at any time. This can be accomplished by doing the following. First, you have to generate a Repository holding the UI elements you want to address in your recording. Then, you simply need to associate this repository with your recording and add actions to your recording referring to the UI elements stored in your repository.
The VIP database application, which is included in your Ranorex installation, is taken as a sample application in this blog to illustrate how to generate a recording and the associated repository without the use of the record button.

Manually generate a Ranorex Recording
The RepositoryFirst of all you have to add a repository to your project (Project->Add->New Item->Repository).
To analyze your application and determine which UI elements are necessary for the recording, open Ranorex Spy.
Let’s have a look at text boxes within the application. By tracking the “first name” text box you will get following RanoreXPath:
![]()
You can now simply add this control to your repository by right clicking on it and choosing “Add to repository”.
If you’d like to directly add all available text boxes to your repository, you have to add a filter to your RanoreXPath. Therefore, open the Advanced RanoreXPath Editor by clicking on the magic wand which is placed next to the RanoreXPath and uncheck the check box for “controlname” to make the RanoreXPath not only fit to this particular text box with the control name “tbFirstName”.
By verifying your altered RanoreXPath, you will see that 5 elements have been found. To see which controls have been found, click on “Highlight”. As you can see, not only all text boxes, but also all labels fit this RanoreXPath as all of these elements are represented with the text adapter. To filter out only the text boxes – as you do not need the labels within our recording – just check the check box “controltypename” and choose “TextBox”. By verifying this RanoreXPath, you will see that only 2 elements have been found – the 2 available text boxes.
After filtering the needed controls (click OK to close the Advanced RanoreXPath Editor), you can add these controls to your repository by right clicking on the parent folder of the two fitting elements in Spy and choosing “Add Matching Children to Repository”.
To learn more about the RanoreXPath and the Advanced RanoreXPath Editor please have a look at following chapters of our user guide:
After adding the relevant text boxes, let’s add the list items stored in the category list box to the repository. Therefore, track a list item, select the parent list node, right click and choose “Add to Repository (incl. children).
Now that you have the text boxes for first and last name and the list items for the different categories stored in our repository, let’s add the radio buttons for the gender and the add button to your repository.
After doing so, the repository should look something like this:
To make your repository hierarchy cleaner, you can add corresponding folders for each type of control (Add New Item -> Simple Folder):
The RecordingAfter adding the necessary controls to the repository, it’s time for creating a recording file (Project->Add->New Item->Recording).
Now you have to connect the newly created recording with the repository created before. This can be done by choosing the repository from the repository list:
After connecting the repository to the recording, you can start with adding actions to your recording table.
The first step which should be done is to start the application under test. Therefore add a “Run Application” action (Add New Action -> Run Application) and choose the executable of the VIP database application.
After that, set the first and last name of the VIP. To do so, you can simply drag & drop the wanted repository item from the repository to your recording. From the context menu that pops up choose “Key Sequence” to use the keyboard to set the value of the text box.
To select a category drag & drop the specific list item from your repository to your recording and choose “Invoke Action” as action type. As action name choose “Select” to select the given list item.
Choosing the gender can be handled the same way as choosing the category.
Pressing the add button can be performed by dragging & dropping the button from the repository to the recording and choosing “Mouse” as action type.
Finally, you can close the application by dragging & dropping the application folder from the repository to the recording and choosing “Close Application” as action type.
Voilà… a recording manually generated without using the record button.
As you can see, you can manually generate a recording from a repository which might be useful
The Ranorex test suite enables you to easily manage your test cases, as well as build robust data-driven tests. Your test automation modules can be shared, adopted, and used within your team. Learn why Ranorex module projects are the best way to group your test modules and reuse them in different test suite projects within your teams.

Organizing a Test Automation Project with Ranorex Test Suite
In order to perform professional testing of an extensive software product, it can be beneficial to separate the views of the testing process.
On the one hand there might be a team consisting of e.g. a Test Automation Engineer and some testers. This team is responsible for covering all conceivable work flows and dividing these workflows into small, reusable modules.
On the other hand there might be a tester. The tester, for his part, is responsible for testing specific work flows processed by the software under test. As the team already has provided all necessary modules, the tester only has to put the desired modules together, to fulfill the required work flow.

Different Views
Separation of ModulesAs mentioned before, it is useful to separate specific work flows in small self-contained modules in order for them to be reused in different scenarios.
These modules can either be recordings or user code modules which will be prepared by a team to allow the tester a rapid generation of different workflows.
To allow a more general approach the team can add variables to the particular modules. The tester only has to provide values by parameters or a data source and to bind the specific columns of this data source to the specific variables.
For more details about data driven testing and parameter usage please have a look at following chapter in our user guide: Data-Driven Test Automation

Separation of Modules
Multiple Projects, One Solution DLL Type ProjectsTo allow collaboration of a team and the tester, the team has to provide the generated modules to the tester.
This can be established by providing Ranorex Test Suite libraries holding specific test modules.
These libraries can be referenced in the Test Suite project of the tester and all modules held by these libraries will be available for the tester to add to his specific test cases.
These libraries include all recording and user code modules generated by the team as well as the repository holding the elements the modules are accessing.
Let’s have a look at Ranorex Studio and how such a test project with several Test Suite libraries would look like.
First of all the Test Suite libraries have to be referenced to make them reusable for the tester.
This can be done by opening the .Net Assembly Browser“ tab at the Add Reference” dialog (Project->Add Reference) and simply adding the generated DLL files. After this step the DLLs should be viewable in the reference list in the project view pad.

Reference list in Project View
The referenced Test Suite libraries are also viewable in the Ranorex Module pad with all their modules and variables.

Module Browser View
The tester can now simply drag and drop the individual modules from the module browser to his Test Suite to construct the specific test cases.

Drag/Drop Modules form Module Browser to Test Suite
EXE Type ProjectsTo handle different test scenarios you can add several Test Suite configurations for your Test Suite.
By modifying the Test Suite configurations, different test cases or folders in your Test Suite can be selected to be executed.
Have a look at following chapter of our user guide to learn more about Test Suite configurations: Running a Test Suite
If modifying the Test Suite configurations does not fulfill the requirements, it’s also possible to add several Test Suite projects to one solution.
Each of these Test Suite projects in a solution will then generate an executable.

Exe Type Projects

Ranorex Solution with several Test Suite Projects
Additional to the automatically generated ones you can add other project relevant files to your projects, like your application under test or files holding the test data provided by your data connectors.
To ensure that these files will be available within the test project by distributing it on other machines – as described in the next chapter – you have to open the properties tab of the added file and set the “Copy to output directory” option to “Always”.
Execution on Runtime MachinesThe generated test projects can be distributed to every machine, which has at least the Ranorex Runtime License installed.
To execute a test project on a runtime machine, you have to copy the executable (*.exe), the Test Suite file (*.rxtst) and the used libraries (*.dll) to a folder on the machine.
These files are by default already in the output folder of your project.
There are two different methods of executing a test project on a runtime machine:

Execution on Runtime Machines
Working on the same solution with different usersAs illustrated in this article, using libraries it is possible to share a whole Ranorex Solution between the team and several testers. The team provides libraries in form of DLLs which are referenced by the tester in the Test Suite project.
That means everybody (testers and team) is working on the same Ranorex Solution.

Working on same Ranorex Solution with different user
To make this scenario work comfortable, it’s recommended to use a source versioning system like SVN (which integrates in Ranorex Studio), having the advantages of
to name some of them.
You can find some hints regarding Ranorex and SVN settings at this blog post.

Using source versioning system
By following the mentioned approaches it will be easy for you to organize a professional testing environment for your extensive software project.