Skip to content

Software Development News: .NET, Java, PHP, Ruby, Agile, Databases, SOA, JavaScript, Open Source

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager! Latest News
Syndicate content
Updated: 13 min 52 sec ago

How to Combine Ranorex and NeoLoad Tests

Thu, 10/20/2016 - 14:43

Let's be honest: We rarely test the product functionality under load. But how can we be sure our end product works when our customers are using it? As we've described in our previous blog post "Combining Automated Functional and Load Testing", it often makes sense to combine functional and non-functional tests. A functional test, which works fine in idle conditions, might fail when the back-end server is under load. Just like simply stressing a back-end system may not reveal functional issues, which can only be found by an automated functional test. If we want to find those errors that only occur under load, we have to combine automated functional tests and automated load tests.

We're happy to announce that you can now combine Ranorex and NeoLoad tests!

In this blog, we want to show you how you can set up the Ranorex-NeoLoad integration and what you can do with it. But first, let's quickly cover the basics:

What is NeoLoad?

NeoLoad is an automated load and performance testing tool from Neotys.

NeoLoad offers a full-fledged REST API to either remote control the execution of a NeoLoad test or transmit timing values to NeoLoad. To enable integration with Ranorex, the REST API calls are wrapped with Ranorex functions and packaged into a NuGet package for easy deployment.

What do I need to enable the Ranorex-NeoLoad integration?

Now that you're all set, we want to show you in detail how you can:

  1. Set up the Ranorex-NeoLoad integration
  2. Use the load testing modules available with the integration
  3. Transmit navigation timing to a NeoLoad test
  4. Update meta-information in cross-browser tests
  5. Upgrade an existing Ranorex project with the Ranorex-NeoLoad NuGet package
Setting up the Ranorex - NeoLoad integration

First, we need to set up the integration:

  1. Add the NuGet package to the Ranorex project
  2. Extend the "app.config" file
Step 1: Add the NuGet package to the Ranorex project
  • Right-click on "References" in the Ranorex project view
  • Select "Manage Packages..."
  • Search for "Ranorex" and add the "Ranorex-NeoLoad integration" package

Manage Packages

 Add NeoLoad Integration Package

This will automatically add the necessary libraries to the Ranorex project. The following code modules will now appear in the module browser:

Added Modules in Module Browser

Step 2: Extending the "app.config" file

To ensure the Ranorex project is properly created, you need to extend the 'runtime' section in the 'app.config' file in the Ranorex project with the following information:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:bcl="urn:schemas-microsoft-com:bcl">
 <dependentAssembly bcl:name="System.Runtime">
 <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
 <bindingRedirect oldVersion="" newVersion="" />
 <assemblyIdentity name="System.Threading.Tasks" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
 <bindingRedirect oldVersion="" newVersion="" />
 <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
 <bindingRedirect oldVersion="" newVersion="" />

Copy code to clipboard

Copy this code and enter it in the 'runtime' section in the 'app.config' file, right after the line <enforceFIPSPolicy enbaled="false" />:

App Config before

Your 'app.config' file should now look like this:

App Config after

You can now use the modules, which are included in the NuGet package, freely within the Ranorex test automation project.

Modules included in the Ranorex-NeoLoad NuGet package

The following modules, and their individual variables, are included in the Ranorex-NeoLoad NuGet package:


This module establishes a connection to the NeoLoad runtime API. This API is used to remote control a running NeoLoad test. It must be initialized before using the following modules: Start/StopNeoLoadTest and Add/RemoveVirtualUsers.

Show the variables available for this module RuntimeApiUri: The Uniform Resource Identifier (URI) of the NeoLoad REST service.
ApiKey: Key stored in NeoLoad to avoid unauthorized access to the REST API. If no key is in use, this variable can be left blank.

Select Edit > Preference to access these variables in NeoLoad.



This module establishes a connection to the NeoLoad data-exchange API. This API is used to transmit external data to a running NeoLoad test (it is not active if no test is running). This module must be initialized before the modules Start/StopNeoLoadTest and Add/RemoveVirtualUsers.

Show the variables available for this module The following three values provide meta information for a running test and can be used in the "filter" functionality within NeoLoad test results.
Location: The location, where the functional test is performed (e.g., Graz, London, Office XYZ, ...)
Hardware: The hardware used where the functional test is running (e.g., Intel i5-5200u). A string describing the utilized operating system is automatically appended to the string defined in "Hardware".
Software: The software, tested in the functional test. When testing a browser, it is recommended to hand over the browser name. When performing a cross-browser test, it is recommended to bind this variable to the column specifying the browsers.
DataExchangeApiUri: The URI of the NeoLoad REST service.
ApiKey: A key stored in NeoLoad to avoid unauthorized access to the REST API (if no key is in use, this variable can be left blank).

Select Edit > Preference to access the last two variables in NeoLoad.



This module starts a NeoLoad test scenario. You need to define the scenario in NeoLoad before.

Show the variables available for this module Scenario: The scenario, as defined within the NeoLoad test, that should be started.
Timeout: The maximum amount of time (in hh:mm:ss) given to Ranorex to start a specific test (recommended value: 00:01:00).

Interval: The time interval (in hh:mm:ss) after which Ranorex retries to start a specific test (recommended value: 00:00:10).

Important: Please make sure to add a leading 0 before a single digit number when entering the timeout and interval values.


This module stops the currently running NeoLoad test.

Show the variables available for this module Timeout: The maximum amount of time (in hh:mm:ss) given to Ranorex to start a specific test (recommended value: 00:01:00).
Interval: The time interval (in hh:mm:ss) after which Ranorex retries to start a specific test (recommended value: 00:00:10).

Important: Please make sure to add a leading 0 before a single digit number when entering the timeout and interval values.


This module adds virtual users to a population, defined in a NeoLoad test scenario. This module can only be used when a test is already running.

Show the variables available for this module Population: The population, as defined in the NeoLoad test scenario, virtual users will be added to.
Amount: The amount of virtual users that should be added to the given population.


This module removes virtual users from a population, which is defined in a NeoLoad test scenario. This module can only be used when a test is already running.

Show the variables available for this module Population: The population, as defined in the NeoLoad test, virtual users will be removed from.
Amount: The amount of virtual users specified that will be removed from the given population.

Transmit navigation timing data from any browser to NeoLoad

Opening a website is related to a certain latency. This latency depends on various factors, such as the network connection or the browser used. It can be measured with the "Navigation Timing" API, which is offered by all browsers. If you evaluate these timing values, especially when the website is under load, you can localize potential bottlenecks. Eliminating the identified bottlenecks will ultimately improve the user experience.

The NuGet package offers a mechanism to calculate these timing values and transmit the results to NeoLoad. You can find a more detailed description of the navigation timing here. The timing values are calculated by the Ranorex/NeoLoad Nuget package:

Calculated Timing Values

Highlighted in green, you can see the timing values that are calculated by Ranorex and submitted to NeoLoad.

To transmit the timing values, you need to drag and drop the repository root element, which represents the DOM of the website under test, into the action table in Ranorex Studio. Once the NuGet package is added to the Ranorex project, the additional entry "SendNeoLoadTimingValues" will appear in the "Dynamic Actions" list.

Please note: This entry only appears if the root element was created after the NuGet package was added to the Ranorex project. You can find a description of how to enable the NeoLoad "capability" in an existing repository here.

Add Neoload Action

The "SendNeoLoadTimingValues" action accepts a "transaction name" as an argument. We recommend using the current page as a transaction name in the Ranorex action table. As soon as NeoLoad receives the timing values of this transaction, a tree with the root node containing the Ranorex test suite is automatically created. Another subfolder is automatically created for the respective transaction name. This folder contains the timing values transmitted from Ranorex.

Add SendNeoLoadTimingValues Action

Resulting Neoload Graphs

Important:  Please make sure to initialize the module "ConnectToDataExchangeApi" before you use the module "SendNeoLoadTimingValues". Otherwise, an error is thrown. 

You can drag the data series into the graph board in NeoLoad to visualize it. If you've provided meta-information, such as "Hardware", "Software" or "Location" in the "ConnectToDataExchangeApi", you can now use this information to filter timing values transmitted from Ranorex.

Update meta-information in cross-browser tests

If you execute the test in multiple browsers, you have to update the filter options in NeoLoad by calling the "ConnectToDataExchangeApi" module again. To do so, bind the data column, which specifies the browsers, with the "Software" argument from the "ConnectToDataExchangeApi" module. You can now compare timing values from different browsers.

Timing Values of Different Browser

Exemplary Ranorex project structure

In the screenshot below you can see an example of how you can use the modules provided in the NuGet package within a Ranorex test project:

Ranorex Testsuite Project Structure

As you can see, a connection to the runtime API is established in the global setup section. The login information take the form of global parameters.
At the very beginning, "StartNeoLoadTest" starts the NeoLoad test scenario. The following test case is data driven and provides the number of virtual users that will be added to the test. These values are provided in "AddVirtualUsers". The inner loop is a cross-browser loop. It defines the browsers in which the test will be executed.

Please note: The module "ConnectToDataExchangeApi" can be called multiple times to update the current browser with the filter feature in NeoLoad.

Upgrade an existing Ranorex project with the Ranorex/NeoLoad NuGet package

If you add the NuGet package to an existing Ranorex project, which already contains a Ranorex Object Repository with repository elements, the modules provided by the NuGet package are automatically available in the module browser. In this case, the "SendNeoLoadTimingValues" option won't be available in the "Dynamic Actions" list for the already existing repository items. Perform the following steps to enable this option:

1. Open the RanoreXPath editor

RanoreXPath Editor

2. Switch to "Browser & Results"

Switch to Browse and Results in Spy

3. Drag and drop the root element from the Ranorex Spy to the matching root element in the Ranorex Object Repository.

Drag and Drop to Repository

Now, the "SendNeoLoadTimingValues" will be available in the Dynamic Actions list for the repository root element that describes the website DOM.


In this blog, you've learned how you can combine Ranorex and NeoLoad tests. You've seen the modules and variables that are available with this integration and how you can transmit timing values to a NeoLoad performance tests. Now, you will be able to validate critical business cases under load conditions to ensure system stability under real usage conditions and identify potential bottle-necks across technology borders.

Further Resources

Register for Free Ranorex-NeoLoad Webinar

The post How to Combine Ranorex and NeoLoad Tests appeared first on Ranorex Blog.

Categories: Vendor

Combining Automated Functional and Load Testing

Thu, 10/06/2016 - 15:34

At conferences, we often get asked how you can increase risk coverage and ensure highest user experience. Fact is that budget constraints and time pressure force testers to achieve maximum results using a minimum of resources. In reality, there’ll always be those problems that occur once the product is released. These are difficult to predict, but can greatly impede the user experience. In this blog we want to show you why it often makes sense to combine functional testing and load testing.

Why performance and functionality of a system are important

First and foremost, an app or website has to work correctly. In an online shop, the user has to be able to open the site, select the desired product, add it to the shopping cart and complete the order. If one of these steps doesn’t work, the user cannot buy the product. This leads to poor user experience (UX) and worst case, results in a lost customer. But also the reliability of a system influences the UX. A site has to work! But it has to work over and over again, even under varying conditions. It has to work when the traffic increases, different browsers are used, but also if new functionalities are added. If a website does not offer reliable performance, customers will shy away from using it. Fact is that functionality and performance are important to the success of your website.

Ideal case: you test every possible scenario. But tests take time and no one’s got time to spare. We need to decide which tests to automate, when and how often. A risk assessment is crucial to pick the right test cases.

Assess risk contribution of potential issues

When creating a test strategy with maximum risk coverage, you have to estimate the probability that certain issues occur and assess their impact on the system. Some functional issues only surface if the system is put under stress. These are particularly hard to predict. However unlikely these issues may be, their impact may just not be worth the risk. Just think about the consequences if a ‘Buy’ button in the shopping cart doesn’t appear on Cyber Monday, when thousands of people access the site at the same time.

Separated automated functional and load testing

Typically, testing types are clearly separated. This is also true for automated functional and load testing. Automated functional testing enables you to automatically and reliably verify the system’s functionality. Load testing verifies the system’s behavior under peak load. A typical sequence of tests could look like this:

Combine automated functional and load testing

With functional automated testing, you first validate if your website or app works as expected. Next, the team tries to manually find bugs while exploring the software. These tests are performed while the system is idle. As soon as they succeed, a performance test verifies the system’s behavior in real usage conditions – varying traffic, multiple users, increased network load, etc. Finally, the team manually validates the system using simulated load conditions.

Downsides of separating load from functional testing

First of all, this testing scenario includes two sections of manual testing. Naturally, manual testing takes a lot of time, is brittle and reduces test coverage. Additionally, your automated functional tests will only provide you with feedback on how your system works in idle conditions. You won’t be able to evaluate the load test results for functional correctness. It is not until the very end of the testing process that you will find out how your system works under stress, in real usage conditions.

Benefits of combining automated functional and load testing

In reality, there will always be those bugs that occur if certain conditions correlate: the link breaks if the site traffic increases or the site content only loads after a refresh. To increase risk coverage and find those functional issues that manifest under load, we need to include load in our automated functional tests. A testing process could now look like this:

Automated testing process 1

You can now incorporate a sustained load in your automated functional tests. This approach to testing enables you to reliably test key functionalities that are most valuable to your business under realistic usage condition. You will be able to identify those issues that only manifest under load early in the testing process, which makes it easier to fix them and will ultimately save you a lot of time. But more importantly, you will finally get tremendously important insights on how end users experience your website. Ultimately, it is up to you to assess the potential impact certain issues may have on your system and if combining these two testing types makes sense in your individual case.

We would like to announce that you can now combine Ranorex functional tests with NeoLoad performance tests!

Read the blog “How to Combine Ranorex and NeoLoad tests” to find detailed instructions on how to combine Ranorex with the NeoLoad performance testing tool! Please note that you will need a NeoLoad license to enable this integration.

You can now already register for our free webinar on “Combining automated functional and load testing”, which will take place on November 09, 2016. In this webinar we will explain in detail how the Ranorex-NeoLoad integration works and what the benefits are.

Register For Free Webinar

The post Combining Automated Functional and Load Testing appeared first on Ranorex Blog.

Categories: Vendor

Integrate Automated Testing into Jenkins

Fri, 09/23/2016 - 11:00

In software engineering, continuous integration means the continuous application of quality control processes — small units of effort, applied frequently.

In this blog we’ll show you how to set up a CI job with Hudson/Jenkins that automatically builds and executes your Ranorex automation as well as automatically sends out the generated test reports for every committed change in a Subversion repository.

Advantages of Continuous Integration Testing

Continuous integration has many advantages:

  • When tests fail or bugs emerge, developers can revert the codebase to a bug-free state without wasting time for debugging
  • Developers detect and fix integration problems continuously – and thus avoid last-minute chaos at release dates
  • Early warning of broken/incompatible code
  • Early warning of conflicting changes
  • Immediate testing of all changes
  • Constant availability of a “current” build for testing, demo, or release purposes
  • Immediate feedback to developers on the quality, functionality, or system-wide impact of their written code
  • Frequent code check-ins push developers to create modular, less complex code
Infrastructure Continuous Integration Tool

You can find a download link and installation description for Hudson and Jenkins here:

In this blog post we are going to use Jenkins as CI tool. There shouldn’t be much of a difference when using Hudson.

As Jenkins or the nodes executing the CI jobs normally are started as Windows services, they do not have sufficient rights to start UI-applications.

Please make sure that Jenkins as master and its slave nodes, where the Ranorex automation should be triggered, are not started as a service.

For the Jenkins master, open the “Services” tool (which is part of the “Administrative Tools” in the control panel), choose “Jenkins” service, stop the service, and set the “Startup type” to disabled:

disable start as service

Use the following command to start Jenkins manually from the installation folder:

java -jar jenkins.war

manually start jenkins

After starting Jenkins, use this address to access the web interface:


To configure your Jenkins server, navigate to the Jenkins menu and select “Manage Jenkins” -> “Configure System”:

Configure System

Note: It is necessary to have the Ranorex main components – and a valid Ranorex license – installed on each machine you want to build and execute Ranorex code.

Source Code Management

As mentioned before, we are going to use a Subversion repository as base of our continuous integration process.

In this sample, we have two solutions in our repository: the application under test and as the automated Ranorex tests.


To start the application under test from your test project, simply add a new “Run Application” action to your action table in Ranorex Studio, which starts the application under test, using a relative path to the repository root:

Run Application Action


As we want to build our code for each committed change within our SVN repository, we need a Subversion as well as a MS Build plugin for Jenkins. An additional mail plugin will make sure that a mail is sent with each build.

Install Plugins

Open the “Manage Plugins” section (“Manage Jenkins” -> “Manage Plugins”), choose the following plugins from the list of available plugins and install them if they are not installed already:

  • MSBuild Plugin
  • Email Extension Plugin
  • Subversion Plugin
Configure Plugins

The installed plugins also need to be configured. To do so

  • open the “Configure System” and configure the “Extended E-Mail Notification” plugin. To do so, set the recipients and alter the subject and content (adding the environment variable $BUILD_LOG to the content will add the whole console output of the build and the test to the sent mail),
    Configure Mails
  • configure the “E-mail Notification” plugin by setting the SMTP server.
  • and navigate to “Global Tool Configuraiton” and configure your “MSBuild” plugin by choosing the “msbuild.exe” installed on your machine.
    Configure MSBuild
Add New Job

Now, as the system is configured, we can add a new Jenkins job, which will update the checked out files from a SVN repository, build both the application under test and the Ranorex automation project, execute the application under test as well as the automation code and send a mail with the report file attached.

Start by creating a new item. Choose “Build free-style software project” as job type and enter a job name:

Add New Item

Configure Source Code Management

Next, we have to check out the source of both the application under test and our test automation project. Start with choosing Subversion as source code management tool. Then, enter the repository holding your application under test as well as your test automation project. Finally, choose “Use ‘svn update’ as much as possible” as check out strategy:

Configure SVN

With this configuration, the application under test as well as the test automation project will be checked out and updated locally.

Add Build Steps

Now, as the source code management is configured, we can start with processing the updated files.
First of all, let’s add MSBuild steps for both projects:

Add MSBuild Buildstep

Choose your configured MSBuild version and enter the path of the solution file relative to the repository root (which is the workspace folder of the Jenkins job) for both the automated and the automating project:

Added MSBuild Buildsteps

With adding these two build steps, the executables will be automatically built. Now the newly built application should be tested.
This can be accomplished by adding a new “Windows batch command” that starts the test suite executable:

Add Batch Buildstep

Added Batch Buildstep

As you can see, some command line arguments are passed to the test suite executable.

In this sample, the command line arguments “/zr”, which triggers the test suite executable to generate a zipped report file, and “/zrf:.ReportsReport-Build-%BUILD_NUMBER%.rxzlog”, which defines the name and the location of the generated zipped report file, are used.

You can find a list of all available command line arguments in the section “Running Tests without Ranorex Studio” in our user guide.
The test suite executable returns “0” on success and “-1” on failure. Based on this return value, Jenkins will mark the build as successful or failure.

Add Post-Build Action

After building and executing the application under test and the Ranorex test script, we will send an email which informs us about the success of the triggered build.
This email should include the zipped report file, mentioned before, as attachment.
To do so, add the new post-build action “Editable Email Notification”, choose the report file location defined before as attachment, and add triggers for each job status you want to be informed about. In this sample, an email will be sent if a job has failed or succeeded.

Added Mail Action

Run Job

Once you’ve completed these steps and saved your changes, check if everything works as expected by clicking “Build now”:

Build Now

After running the generated job, you will see all finished builds within the build hierarchy. Icons indicate the status of the individual builds.
You can view the zipped report files of all builds by opening them in the local workspace (“Workspace/Reports”):

Build History

As configured before, an email will be sent to the specified email address(es), including the console output in the email text as well as the generated zipped report file as attachment.

Add Repository Hook

Now we can manually trigger a build. As we are working with Subversion, it would be beneficial to trigger the script for each commit.
To do so, you can add a server side repository hook, which automatically triggers Jenkins to start a new build for each change committed, as described in the subversion plugin documentation.

Alternatively, you can activate polling of the source code management system as build trigger in your Jenkins job configuration.

As shown in following picture, you can define the interval, after which the source code management will be invoked (e.g. 5 minutes after every full hour):

Added Build Trigger


Following the steps above you will be able to easily setup a continuous integration process performing the automated test of the application you develop. Each commit will now trigger an automated test run. Once the test run has finished, you’ll instantly receive a mail with the Ranorex test report.

Note: This blog was originally published in July 2012 and has been revised to reflect recent technical developments.

Download Free 30-Day Trial

The post Integrate Automated Testing into Jenkins appeared first on Ranorex Blog.

Categories: Vendor

Test Your iOS 10 Apps

Thu, 09/15/2016 - 12:31

Apple’s iOS 10 update for iPhone and iPad lives up to its milestone software version number and implements major changes to your daily phone and tablet routine.

Benefit from features such as:

  • A fully redesigned lock screen
  • Siri open for developers
  • Huge changes and new features for messages
  • A redesigned Apple Music app
  • Deletable stock apps
  • A completely new Home app for HomeKit
  • and many more features.

We are delighted to announce that with our latest release, Ranorex 6.1, iOS 10 is supported.

Upgrade to the latest OS on your mobile devices now to start automating your cutting edge mobile app tests with Ranorex!

Download free trial Learn how to test your iOS 10 app

The post Test Your iOS 10 Apps appeared first on Ranorex Blog.

Categories: Vendor

Ranorex 6.1 Released

Thu, 09/08/2016 - 15:37

We’re happy to announce that we’ve released Ranorex 6.1! This new generation of functional test automation is now fresh and polished to make working in teams even easier! Next to remote test execution, improved test suite file format and Git integration, this software update introduces an intuitive setting storage and a progressive report preview. Let’s have a look at the benefits, shall we?

Solution Settings Ensure everyone in a team uses the same settings when working on a test automation project.

You can now save technology-specific solution settings directly in the test automation solution, while user settings can still be stored locally. This brings some rather fantastic benefits with it:

  • You can check in your settings together with the solution into a version control system. This makes it easier to share solutions with other team members and, ultimately, to work together on them.
  • Are you working on multiple test automation projects? Very likely, each is in its own test environment. Now, when you switch between solutions, you don’t have to manually adjust the settings.

Have fun sharing your settings and working together on test automation projects!

Learn more about the solution settings

Progressive Report Preview For those who’d like to take a peek in the test report during test execution.

We’ve all been there. You’d like to know how many test cases have failed, but it could take hours until the test run is complete and the full report is available. You’d need this information to react early to failed test cases – or maybe just to have a peace of mind before you go home. Trust us, we get it. So here’s what we’ve done: During test execution, test results are saved in configurable intervals. So whenever you feel like it, you can preview the report from anywhere without disrupting the test run. Enjoy!

Learn more about the progressive report preview

For a full list of new features and enhancements, please view our Release Notes. This software update is available now and included in software maintenance at no additional costs.

Learn more about Ranorex 6.1 Download Free 6.1 Trial

The post Ranorex 6.1 Released appeared first on Ranorex Blog.

Categories: Vendor

Manually Create Automated Tests

Thu, 09/01/2016 - 13:00

Ranorex is more than just a simple capture and replay tool. It is a versatile test automation software that offers a range of tools suitable for every skill level. While you don’t need any programming skills to easily create and maintain your tests with the Ranorex Recorder, you can also manually create your automated tests.

What are the benefits of manual test case creation?

  • Keep your Ranorex Object Repository structured and easily maintainable from the start.
  • Create robust test cases that uniquely identify dynamic IDs.
  • Ensure only those UI elements you want to test are available in your Ranorex Object Repository.
  • Automate complex test scenarios in code using the Ranorex Object Repository.


Test Scenario

In this example, we’ll use the KeePass as application under test (AUT). This open source password manager application is one of our sample applications delivered with Ranorex Studio, so you can easily recreate this example.

In this blog, we’ll show you how to

  • generate a Ranorex Object Repository containing exactly those UI elements you want to address in your automated test,
  • drag and drop the resulting repository items to your action table or
  • drag and drop items directly into your user code to represent the workflow you want to test.
The Ranorex Object Repository

The Ranorex Object Repository manages the UI elements of your automated test. A repository item is automatically created in this central Ranorex Object Repository when you record or track a UI element. If you change a repository item, these changes are automatically applied in the code as well as in the recording module.

Start by opening your solution and add an empty recording module. You will notice that the central Ranorex Object Repository of your test automation project is displayed directly below the action table. You can now add UI elements to the repository using the ‘Track’ button in the Ranorex Object Repository.

Track UI Elements

Enhancing the RanoreXPath

You can alter the RanoreXPath of specific repository items to make them more robust. Simply open the path editor and click on the ‘Edit’ button next to the item. For more information about the RanoreXPath, please have a look at the user guide chapters RanoreXPath and RanoreXPath Editor. If you’d like to know how to best enhance the object recognition of your AUT using the RanoreXPath operators, check out the blog post RanoreXPath – Tips and Tricks.

Keep your repository clear and structured

If your Ranorex Object Repository contains many objects, it’s particularly important to keep it clearly structured and organized. Here are two tips:

Rename repository items

Each UI element within the repository can have a logical user-defined name. Renaming repository items and giving them logical names will make it easier to understand test automation code and report files.

Create Logical Folders

You can also create logical folders to structure and group UI elements that logically belong together. For detailed instructions on how to structure your Ranorex Object Repository, please check out our user guide chapter Adapting an Existing Repository.

Keep Repo Clear

The Recording

As your Ranorex Object Repository now contains multiple UI elements, you can add actions to the recording. Do so by either selecting ‘Add New Action’, or simply drag & drop specific repository items from the repository to the action table in the recording.

Add Action Via Menu

Add Action Via Drag Drop

If you’d like to connect data to your automated tests and use variables in the action table or the repository, have a look at the user guide chapter Data-Driven Testing.

The User Code

You can also create your actions directly in user code. Simply drag and drop the specific repository item from the Ranorex Object Repository directly into the code editor.

Add Code Via Drag Drop

In the user guide chapter Code Examples you can find further examples on how to extend modules with user specific code.


As you can see, you can create your automated tests manually without pressing the record button at any time. This will give you more control over the actions that should be triggered.

Download Free Trial

The post Manually Create Automated Tests appeared first on Ranorex Blog.

Categories: Vendor

RanoreXPath – Tips and Tricks

Thu, 08/25/2016 - 14:00

The RanoreXPath is a powerful identifier of UI elements for desktop, web and mobile applications and is derived from the XPath query language. In this blog we will show you a few tips & tricks on how to best use the various RanoreXPath operators to uniquely identify UI elements. You can then use these RanoreXPaths in your recording and code modules to make your automated tests more robust.


Using RanoreXPath operators

Element Browser

The Ranorex Spy displays the UI as hierarchical representation of elements in the Element Browser view. The RanoreXPath can be used to search and identify items in this UI hierarchy.

In this example, we’ll use the tool KeePass as application under test (AUT). This open source password manager application is one of our sample applications delivered with Ranorex Studio. If you have multiple applications open, Ranorex Spy will list them all. Filtering the application you want to test will increase speed and give you a better overview. To do so, track the application node of KeePass and set it as root node (context menu > ‘Set Element as Root’). Now, only the main KeePass form and its underlying elements are visible.

Ranorex Spy

General Layout of RanoreXPath

RanoreXPath expressions are similar to XPath expressions. They share both syntax and logical behavior. A RanoreXPath always consists of adapters, attributes and values:

Layout of RanoreXPath

The adapter specifies the type or application of the UI element. The attribute and values specify adapter properties.

The absolute RanoreXPath of our KeePass form looks like this:

RanoreXPath of AUT

The form is an adapter specifying the type or classification of the UI element. It is followed by the attribute value comparison, which identifies the requested element. In this example, the comparison operator is a simple equality.

If you want to know more about how the RanoreXPath works, we recommend our dedicated user guide section.

Search for multiple button elements

You can list all buttons elements that are direct children of a designated positon in your AUT. Have a look at these two examples:

1. List all buttons that are direct children of the KeePass toolbar:

To do so, simply set the toolbar as root node and type ./button into the RanoreXPath edit field, directly after the given RanoreXPath.

Relative path to all child buttons

This will create a relative path to all child nodes of the actual node, which are buttons.

Element Tree with Child Buttons

2. List all buttons of your AUT:

Navigate back to the form adapter, set it as root node and type in .//button.

Relative path to all buttons

You’ve now created a relative path to all descendants of the actual node, which are buttons. These are all buttons of all levels of the subtree of the current element.

Element Tree with all Buttons

Identify controls with a specific attribute

You can also create a path to controls, to filter them according to specific attributes. In this example, we want to find all checked checkboxes.

Open the “Find” dialog in KeePass (<CTRL><F>), as this dialog contains checkboxes, and set it as root node. Now, you can validate which item of the checkbox control has the attribute “checked” set to true. To do so, enter “//checkbox[@checked=’True’]”:

RanoreXPah for Checked Checkboxes

As you can see, only the checked checkboxes will be visible in the Element Browser.

Element Tree with all checked checkboxes

Identify checkboxes by combining attributes

You can further extend the previous example by combining attributes. This enables you to, for example, omit certain items from the search, or search for specific items.

1. Omit a specific item from the search

You can omit a specific item from the search using the “not equal” operator and the “and” conjunction. In this case, we want to omit the item “&Title”:

RanoreXPah for Checked Checkboxes excluding Title

Element Tree with all checked checkboxes excluding Title

2. Seach for specific items

You can use the “or” instead of the “and” conjunction to extend your search and only look for specific items. Extend the checkbox search to look for the items “&Title” and “&URL”:

RanoreXPah for Checkboxes

Element Tree with checkboxes

Recognize related elements using the parent operator

After running the Ranorex desktop sample project, there will be two entries in our AUT – one for a WordPress and one for a Gmail account. In this case, we’d like to find the username of the “Gmail” KeePass entry:

RanoreXPah for username of gmail entry

Element Tree username of gmail entry

Username of gmail entry

Start with the RanoreXPath to the cell containing the text “Gmail” (framed in red). Next, use the relationship operator “parent” to reference the parent node of the current element. In this example, it’s a row (framed in blue). The index “[2]” navigates to the second cell, which contains the Gmail username (framed in green).

Recognize related elements by using preceding- and following-sibling

Another way to search for related elements is to use the relationship operator “preceding-sibling”. In this example, we want to find the title of a KeePass entry based on its username.

Relationship operators

The command “preceding-sibling::cell” lists all preceding cells. In this case, the result is the title (framed in green) which corresponds to the given username (framed in red).

RanoreXPath Preceding Sibling

Element Browser Preceding Sibling

In contrast, the command “following-sibling::cell” delivers all following cells. In our case, these are all following cells (framed in blue) that correspond to the given username (framed in red).

RanoreXPath Following Sibling

Element Browser Following Sibling

Identify attributes fields using regular expressions

You can also use regular expressions in attribute conditions to identify attribute fields. In this example, we’d like to filter cell adapters that contain an email address in their text attribute. Regular expressions matching an email address may look like this: “.+@.+\..+’”.

RanoreXPath Regular Expression

Element Browser Regular Expression

The “~” operator instructs Ranorex to filter attribute fields using a regular expression. The “.” in our regular expression matches every single character, while the “+” specifies that the preceding element has to occur one or more times. To escape special characters (such as “.”), enter a backlash before the character.

In our example, every expression will match that contains the character “@” with one or more characters before and after it, followed by a “.”, which is followed by one or more characters.

For more examples on how to use regular expressions in RanoreXPaths, please have a look at this user guide section: RanoreXPath with regular expression.

Identify attributes with dynamic values

Dynamic attribute values change each time an element is displayed anew. Fortunately, dynamically generated content usually has a prefix or postfix. To identify dynamic elements, you can either use regular expressions, as described above, or use the ‘starts with’ or the ‘ends with’ comparison operators:

  • ‘>’: The value of the attribute must start with the given string
  • ‘<‘: The value of the attribute must end with the given string

The RanoreXPath enables you to find and uniquely identify every single UI element of desktop, web and mobile applications. You can use the RanoreXPath operators to make your test suite more robust and identify even dynamic attribute values.

RanoreXPath Overview  RanoreXPath Editor 

The post RanoreXPath – Tips and Tricks appeared first on Ranorex Blog.

Categories: Vendor

Smartwatches – Here to Stay & Here to Test

Thu, 08/04/2016 - 12:36

Smartwatches are no longer a second screen to the mobile device. This year, Android has released their marshmallow version for Android Wear, adding yet more features to the smartwatch. Likewise, also developers seem to be kicking it up a notch. It’s no stretch to say that testing will have to adapt to a wearable mindset to face these new challenges. We proudly announce that Ranorex supports Android Wear testing. As always, you can rely on us to stay prepared and stand your ground on the consumer market. But first things first. Let’s start with why smartwatches are such a hot topic in 2016.

Getting off the starting blocks

It seems that fiction is about to become reality. Gadgets are already used to ease our life in almost every area – be it health, entertainment or personal organization. In their February 2, 2016 press release, Gartner* predicts that “274.6 million wearable electronic devices will be sold worldwide in 2016, an increase of 18.4 percent from 232.0 million units in 2015 (see Table 1). Sales of wearable electronic devices will generate revenue of $28.7 billion in 2016. Of that, $11.5 billion will be from smartwatches.”

It’s a given that vendors want to throw their hat into the ranks and join the game. More vendors provide users with plenty of options to choose from. And with the rise of wearables, the pressure’s on for developers. So what does it take to be successful?

The game’s on for smartwatches

Naturally, users expect both hard- and software of smart wearables to function flawlessly. But smartwatches have to be more than just an expensive secondary screen to a mobile device, merely saving the user from getting the phone out of the pocket. They’ve got to be useful. Today it’s all about user experience to keep the excitement going. As customers are presented with an ever increasing choice in smartwatch products, the challenge is on for app developers to provide the best use case and the most appealing functionality. The question of how you can make your app an incentive for using a smartwatch goes right in hand with one question: How can you best react to arising challenges when it comes to smartwatch app testing?


Ranorex Smartwatch

In for the win – with Ranorex Android Wear testing

When it comes to testing an Android smartwatch, challenges are definitely usability, device fragmentation and dependency on a mobile device. Here’s a short overview of how Ranorex can help you deal with these challenges:


Smartwatches come in all forms and sizes. Software has to be able to adapt quickly to ensure highest usability in this ever-changing market. Considering that Android Wear supports square as well as round displays and screen sizes go as small as 1.3 inches, this is definitely a challenging task for developers. With such a restricted screen size, software has to be functional and easy to use. At the same time, it has to be highly adaptable to be appealing and thus desirable no matter the form or screen size.

Ranorex is flexible
With Ranorex, it doesn’t matter which Android Wear smartwatch your app will later be used on. Record your test once and run it on different Android Wear watches. How? We know that test scripts have to be reliable and robust to ensure high quality software. That’s why Ranorex doesn’t rely on a coordinate level, but uses the powerful RanoreXPath to uniquely identify even dynamic user interface elements on your Android Wear device, making your test scripts robust against UI changes.

Dependency on mobile device

Smartwatches aren’t (yet) a standalone gadget, but are highly dependent on a mobile device. This is why you’ll also need to test your smartwatch app on a mobile device – be it mobile phone or tablet. And who knows what’s yet to come. The many possible use cases arising from device fragmentation will definitely pose a challenge.

Ranorex offers an all-in-one license
We’ve got good news. You only need one license to test any kind of mobile, web or desktop application with Ranorex. You can test your app on your mobile device and on your smartwatch. Should you decide to venture out and perform additional cross-technology testing, we’ve got you covered: you can reuse your test case across multiple devices. You also don’t need an additional license to use the wearable testing functionality. No additional license means no additional costs. So all there’s left for us to say is: happy testing.

Time pressure and quality enhancement

As we’ve mentioned in our 2016 Test automation trends blog post, time pressure is an imminent factor when it comes to releasing software, while providing highest quality software remains a prerequisite to compete in the fast-growing wearables market.

Different automation approaches and integration into existing testing environments
Working together in teams is essential for a timely release. As Ranorex offers a broad set of automation tools, every member of your testing team can feel comfortable working on a test automation project. Ranorex is more than just a Capture & Replay tool, but a software that supports collaboration between developers and testers. While you don’t need any programming skills to create robust and easily maintainability tests with the Ranorex Recorder, developers can add further functionalities or create new test automation projects entirely in C# and VB.NET.  You can also seamlessly integrate Ranorex into any development environment, using CI and version control systems. Additionally, our latest major software update, Ranorex 6.0, comes with functionalities that make working in teams even easier: Remote testing, Git integration, code editor enhancements and many more features you’ll definitely love.


Do you want to know more about how you can test your Android Wear app with Ranorex? You can find detailed instructions in our Android Wear user guide section.


Learn how to test Android Wear apps Download Free Trial 



*Gartner, Press Release, “Gartner Says Worldwide Wearable Devices Sales to Grow 18.4 Percent in 2016”, February 2, 2016.

The post Smartwatches – Here to Stay & Here to Test appeared first on Ranorex Blog.

Categories: Vendor

Integrate Automated Testing into Any Continuous Integration Process

Wed, 07/20/2016 - 08:24

Long gone is the time of waterfall’s strictly separated development & testing phases. Today, it’s all about fast feedback, quick iterations and frequent releases at a previously unseen velocity. It requires an agile methodology to keep up with the high demands. Your team’s success depends on a supporting infrastructure with the right tooling. Without any doubt, automation plays an essential role here. Our tip: Integrate test automation into your continuous integration (CI) process.

We wouldn’t want you to waste precious time if you’ve your development environment already set up. That’s why you can integrate Ranorex into any continuous integration process. Let’s have a closer look at the benefits of integrating test automation into your CI system, and how you can do it:

continuous integration automated testing overview

Automated testing and continuous integration

The idea of continuous integration is to frequently promote code changes and rapidly get feedback about the impact these changes have on the application or system. Including test automation in the development cycle enables you to automatically test each incremental code change.

So basically every time a developer commits code changes to the version control system (VCS) such as Git or TFVC, a build of the application under test as well as the Ranorex test automation project is triggered in the CI system. The resulting test automation executable then runs against the application under test.

To evaluate the outcome of the automated test, the continuous integration tool examines the return value of the executable or its output text (e.g. “TEST FAILED” for failure). With Ranorex, the return value ‘0′ signals the successful execution of the test script, while the return value ‘-1′ signals a failure. Each team member automatically receives a notification about a finished build. This notification includes build logs as well as a test execution report.

Advantages of integrating Ranorex into your CI system:
  • As each code change is immediately tested, potentially introduced bugs are found faster, which ultimately makes it easier to fix them.
  • The test automation report enhances transparency, as each team member will receive instant feedback about the state of code.
  • There’re no integration problems, as Ranorex can be integrated into any CI tool.
Setting up Ranorex test automation in your CI system

Note: You have to install Ranorex on each machine you’d like to execute Ranorex tests on. You’ll need a valid license to do so. Please find more information about Ranorex licenses on our dedicated Pricing page.

Each committed change in the application under test and the test automation project should be automatically tested. In other words, every change should trigger these 3 steps:

  • building the application under test
  • building the Ranorex test suite
  • executing the Ranorex test suite

continuous integration automation testing in detail

First, you need to manually set up these steps in your CI system.

1. Build the application under test

The first build step should generate an executable of your application under test. This executable should later be triggered from the Ranorex test suite project.
Thus, add a build step which will build your application under test (e.g. MSBuild build step, Ant build step, 

2. Build the Ranorex test suite

In this second step, you’ll need to generate an executable to automate your application under test. To do so, add a build step (MSBuild or Visual Studio) and choose the project file (*.csproj) of your Ranorex project which should be built.

3. Execute the Ranorex test suite

The third step should execute the previously created executables. Simply add an execution step triggering the *.exe file of the test automation project and define the command line arguments if needed.

The test execution should now be triggered on the same system the projects were built on. If you want to trigger the execution on another system, you need to deploy the built executables and all connected files to that system. Please make sure to execute the application under test and the Ranorex test suite in a desktop and not in a console session.

Automated testing of frequent code changes

If the code of your application under test or your test automation project changes frequently, it doesn’t make sense to run the entire test suite including all test cases with every build. Instead, you should run only those test cases that are affected by the changes. How? Run configurations!
You can add and edit run configurations directly in the test suite (see user guide section ‘Running a Test Suite’).

You can trigger a run configuration using a command line argument. The following command line, for example, will run the test suite executable ‘TestCIProject’ with the run configuration (/rc) ‘SmokeTest’ and generate a zipped report file (/zr /zrf) ‘Report.rxzlog’ in the folder ‘/Reports/’.

TestCIProject.exe /rc:SmokeTest /zr /zrf:Reports/Report.rxzlog

Interested in more command line arguments? You find more in the user guide section ‘Running Tests without Ranorex Studio‘.

Test automation report – the importance of feedback

“No news is good news” is definitely not true for agile teams. It’s important that everyone in a team – whether it is a developer or tester – knows about the state of the code and, thus, the outcome of the automated test run. It really couldn’t be any easier: Simply add a post build action which sends a mail to your team members with the build log and the generated zipped report attached.

Integrate Ranorex into a specific CI system:

You’re using a specific CI tool? Whether it’s Bamboo, Jenkins, HP Quality Center, TeamCity or Microsoft Test Manager – check out the section below to find a detailed instruction on how to integrate Ranorex into your CI tool!

As you can see, it’s easy to integrate Ranorex test automation in your continuous integration system. Each code change in your application under test and your test automation project will be automatically tested, which enhances transparency and enables you to find bugs faster.

You want to know about the benefits of integrating Ranorex into your development environment? Try it out! Download the full-featured 30-day Ranorex trial and see the benefits for yourself! Have fun integrating!

Download Free Trial

The post Integrate Automated Testing into Any Continuous Integration Process appeared first on Ranorex Blog.

Categories: Vendor

Keyword-Driven Test Automation with Ranorex

Thu, 07/14/2016 - 10:15

Multiple releases, limited resources, time pressure and a team with mixed skillsets. And it’s your task to create flexible, maintainable automated tests, which every team member can understand and work with. The solution: get a test automation tool that supports keyword-driven testing.

What is keyword-driven testing?

The keyword-driven testing approach separates the test automation implementation from the test case design. A keyword is defined for each action in the test case. Once the keyword is set, you don’t need any programming knowledge to easily design and maintain the automated tests.

What are the benefits of keyword-driven testing?
  • Tests are easily readable.
    As keyword-driven tests are technology-independent, they’re easily readable for non-technical testers. While technically experienced team members can prepare the automation process and define keywords, you don’t need any technical knowledge to design test cases with these keywords.
  • You can create flexible, easily maintainable tests faster.
    In keyword-driven testing, each action is automated only once and the corresponding keyword can be reused throughout several test cases.
How can I create keyword-driven tests with Ranorex?

There are two ways of creating keyword-driven tests with Ranorex:

1. Keyword-driven framework with automation modules

You can use both your recording and code modules in Ranorex Studio as a basis for keyword-driven testing. Simply split your automation modules and give them each a clearly understandable name. For example, you can define a set of actions, which start the system under test, as a module with the name “StartSUT”. You can find detailed information on how to do so in this user guide section.

Drag keyword from module browser for keyword driven test automation

These modules now function as keywords. Once the keywords are defined, you can drag and drop the keywords needed for your test directly from the module browser into your test suite.

Reuse keywords in multiple projects

Start by creating your keywords directly in a Ranorex test suite module library. You then use these keywords in multiple Ranorex projects by referencing back to this library. You can do so in two different ways:

  • Reference the Ranorex test suite module library. This enables you to still edit the keywords when needed.
  • Reference the DLL file of the Ranorex test suite module library. Please note that this approach doesn’t allow you to modify your keywords.

This approach completely separates the keyword implementation from the test case design and the keyword usage.

Separation in several projects for keyword-driven approach

If you want to learn more about organizing test automation projects, please read this blog post: “Organize a Test Automation Project with Ranorex“.

Use external data in keyword-driven tests

You can make your tests even more flexible by using variables. Variables enable you to automatically retrieve external data, which you’ve saved in an Excel or CVS sheet, in your tests – such as passwords for login actions. You can find detailed information on how to implement this type of testing in our user guide section “Data-Driven Testing“.

2. Keyword-driven testing using the action table

We bet you’re familiar with the good old Excel-spreadsheet. So why not use something you already know well in your automated tests? When using the action table in the Ranorex Recorder, you can create keyword-driven tests in a table-like workspace. It just takes a little trick to access your predefined keywords within this view: Inheritance.

Technically experienced team members can provide code-based keywords in a code module. You find detailed information on how to do so in this user guide section or this blog post.

Keyword Implementation

A recording module, which is inherited from a code module, automatically derives all functionalities from its parent module. This is also true for parameters – you can read more about this topic in the user guide section “User Code Actions and Parameters”.

This can be achieved with inheritance in the recording modules “UserCode.cs” file:

Inheritance From KeywordLibrary Module

Now, you can simply add a user code action in the action table (Add New Action -> User Code) and choose a predefined keyword. Once you’ve defined it, you can set the argument.

Keyword Driven Action Table

You can also use data-driven testing within the recording module by simply making the keyword parameters variable as explained in the user guide section “Data-Driven Testing“.


Keyword-driven test automation is a fantastic way to create flexible test cases. It enables teams with different technical background to work on test automation projects together, while keeping test clearly structured and easily maintainable.

Download Trial

The post Keyword-Driven Test Automation with Ranorex appeared first on Ranorex Blog.

Categories: Vendor

Test Automation Day 2016 – Insights

Tue, 07/05/2016 - 11:52

Conferences are always a fantastic way to meet people and exchange ideas with other test automation experts. The Test Automation Day is a major software testing conferences that is dedicated to test automation. This year, it took place in Rotterdam, the Netherlands, on June 23rd. This inspiring conference was packed with test automation experts, software testing professionals and leading IT organizations. Not only did we get to listen to thought-provoking keynotes, but also had interesting talks at our Ranorex booth. Here are some of the most frequently asked questions at our booth:

Is Ranorex just a Capture & Replay tool?

Ranorex is more than a just simple Capture & Replay tool. It is a versatile test automation software that offers a range of tools suitable for every skill level. While you don’t need any programming skills to create and maintain your tests with the Ranorex Recorder, you can also create your automated tests manually.

How can I create my automated tests without using the Ranorex Recorder?

Test automation engineers will especially love the Ranorex Spy. It is a powerful tool that enables you to obtain UI elements from your application under test. Simply open the Ranorex Spy in Ranorex Studio and track the UI elements you want to automate. You can drag these elements directly from the Ranorex Spy into the central Ranorex Object Repository. From there, you can then further drag them either into the action table, or the code editor. Here’s where it gets interesting: Usually, UI elements are used more than once in each test case. When adapting an element in the central repository, this change will be true for all occurrences of this element – both in code and in the action table. The benefit? You don’t have to adapt each element manually, which will save you a lot of time. How does Ranorex support the collaboration between developers and domain testers?

The Ranorex Object Repository is the central point of collaboration between developers and domain testers. This central repository is used to manage UI elements. When you record a UI element with the Ranorex Recorder, or track an element with the Ranorex Spy, Ranorex will automatically create a repository element in this central repository. Thus, when changing a repository element in the Ranorex Object Repository, the changes are automatically applied both in the code and the recording module. This does not only ease team collaboration, but also test maintenance.

How does Ranorex support creating and editing test automation projects in code?

If you’re into coding, you’ll benefit from the Microsoft .NET framework and can write code in C# and VB.Net. You’ll also love the new code editor enhancements, which have just been released with our latest major software release: Ranorex 6.0. You can find further information on the new code editor features in this blog post.

Does Ranorex support automated testing of mobile applications?

Ranorex enables automated testing of mobile Android and iOS applications. You can test hybrid, native and mobile web applications. The benefit? You can connect your mobile device to Ranorex Studio using either a USB or Wi-Fi connection. For more information on mobile test automation with Ranorex, please visit our dedicated Ranorex User Guide section.

At the end of this blog post, we just couldn’t resist letting you in on this hilarious incident that occurred at the Test Automation Day this year. Unaware of what was about to happen, we’re busy talking to prospective clients at our Ranorex booth, when a woman came up to us and asked: “May I touch your balls?”. :-) We’ll leave it up to you to imagine the look on our faces!


TAD Rotterdam Ranorex


Download Trial

The post Test Automation Day 2016 – Insights appeared first on Ranorex Blog.

Categories: Vendor