Open UI: Testing with Selenium

Selenium is a browser automation tool, that allows web projects to automate repetitive tasks. As an early pioneer of Open UI, I found this new capability to be incredibly useful for achieving continuous integration. I gave readers a hint of this last year, in the article "Open UI - Build Process", which left readers with a list of ingredients, and a plan to manage their build automation.

Now that more Siebel projects around the world are on embarking on upgrading their Siebel Applications to Siebel Open UI. Its about time we advance this concept into something more tangible that Clients can benefit from.

Picture this... as part of the Open UI upgrade, you are required to navigate to 1000+ views in Siebel and test for WCAG defects in all 3 major browsers. That isn't so exciting.

Testing for Open UI defects requires a high level of thoroughness to ensure that entire your Application is compliant, and remains compliant in the future. The move to Open UI will expose poor configuration practices that might have been passable in HI, but will break in Open UI. Open UI will also introduce defects as a side effect of the upgrade.

The simple approach to this problem is to brute force it, and assign a team of developers to navigate to each view to analyse for technical defects. But this isn't really viable, as a long term strategy, a smarter approach is to use web automation.

Web automation brings to mind images of robots that are used to scrape web sites, harvest email addresses and index content, but Siebel developers have a more important itch to scratch: Testing the Siebel UI.

The obvious use case is to run continuous integration testing, to ensure that new builds are thoroughly tested over night. A more advanced crawler can be built to perform functional testing of the applications main areas, but the scope of this article is to show how you can build your own Open UI crawler that can be used to programatically navigate to each view, and optionally validate your application.

Theres no shortage of tools in the market that is available to perform this sort of work, but if we narrow our criteria to open source web automation solutions, the Selenium web driver makes a pretty good choice, as it's also set to become a W3C recommendation. Selenium works with all the major browsers, is compatible with your favorite programming language, and it is also free.

This article will provide you with a sample application that implements Open UI automation with Ruby, but you can extract the lessons learnt from this article, and implement them in your language of choice.

I've chosen to use Ruby as my language, because there is solid support for web automation. Ruby has gems that allow the developer to easily parse the DOM, make selections using CSS or XPath syntax, deal with dialog boxes, and take screen shots of problem views. Combining with this Watir, which is a selenium wrapper in Ruby, allows the developer to build the automation quickly in a light weight language.

The solution for your project may be different, if you require enterprise support, headless servers, or if you plainly prefer to stick to your language of choice, because of your available skill set, then the right tool for your circumstance will be different. The most important ingredient here is Selenium, or in this case Watir, which is a Ruby flavor of Selenium.


This is the Browser automation API that allows you to control your browser programatically

" Selenium automates browsers. That's it! What you do with that power is entirely up to you. Primarily, it is for automating web applications for testing purposes, but is certainly not limited to just that. Boring web-based administration tasks can (and should!) also be automated as well."

Browser Support

Chrome, Firefox, IE...

Remote control drivers

Javascript, Java, C, Ruby, Perl, PHP...

Open UI

The crawler can be run against a thin client, or against a local thick Client running Open UI.

Ruby Implementation

Knowing Ruby isn't a prerequisite to understand this concept. Ruby is a pretty readable language, and I've added a good dosage of comments to explain what the code is doing so those from non Ruby backgrounds can follow.

#import required libraries
require 'rubygems'
require 'watir-webdriver'
require 'cgi'

#Parametise the URL that will be used to navigate to the Open UI application
#This should really be configured for a server URL for real testing
#but im using a local URL for this example
sURL = "http://localhost/start.swe?"
sPass = nil
sUser = nil

#Open a new chrome browser session
browser = :chrome

#navigates to the URL defined above
browser.goto sURL

#maximise the window so we can see all entire view

#This block simulates the user login process for thin client connection
#else it is bypassed for the thick client
if sUser!=nil && sPass!=nil
     #fill in username in the user name field
     username = browser.text_field(:name, "SWEUserName")
     username.set sUser if username!=nil
     #fill in password in the password field
     password = browser.text_field(:name, "SWEPassword")
     password.set sPass if password!=nil
     sleep 1
     #click the login button =>"Login")
sleep 5

Congratulations!. At this point we have just created a simple crawler that has logged into an Open UI Application.

Next we want to tell it how to navigate the application, by going to the sitemap, read all the views, and parse all the JS links embedded in the view elements. This is done pretty easily in Ruby.

     #use CSS to locate sitemap icon, and click it 
     browser.element(:css => "li[name=SiteMap] > img")

     #use CSS selector to read all the views in sitemap into an array
     #these links also contain an onclick attr that allows to emulate a view navigation
     links =browser.css("span[class='viewName'] > a")

Finally, we loop through every link, execute the JS code to perform the navigation, and optionally perform any automation.

     links.each do |link|
     params = CGI.parse(link.attr("onclick"))
     sleep 5
     #Goto view
     browser.execute_script( link.attr("onclick") )

Thats as simple as it needs to be.

To fire it up with a dedicated client, you'll first need to open up an existing session to start the local web server. When the above code is run, it will launch a new browser connecting to the existing session.

For thin client connections, it is not necessary to pre-launch the session, the above code will instantiate a new browser session, and will login in normally.

A crawler like the program above, can navigate the application, verify each view and flag views that have issues.

Building a simple crawler is a easy, and is something that you can give to an energetic graduate to perform in a day, however if you require a crawler that can be a workhorse for your Continuous Integration strategy, then it needs to be a little more robust, and more scalable than the simple example above, or if your needs warrant a more specialized crawler, that can check for and enforce WCAG compliance in your application, then you'll ideally need a plugin system that can allow you to easily add new validators. If want to go a little further, and build in functional testing capabilities, then could build an API bridge to facilitate a DSL to build more readable test cases.

Open UI + selenium opens up these exciting opportunities. For my client, having a nightly build process + continuous integration, and WCAG reporting, ensures they have a strict standards compliant UI and a more stable application for every deploy.

This article provides the necessary ingredients, and a simple recipe for other Siebel customers to follow the same path.

Further Reading

Selenium Web driver
Continuous Integration

More on Open UI

Serious Open UI developers should be on the watch, for the up comming Open UI book from some very distinguished authors

Siebel Open UI Developer's Handbook



  1. Hi, we have siebel crm with high interactivity mode. Using selenium webdrvier, can we automate it using java language ?

  2. Hi Vish, The straight answer is yes, but the ActiveX controls, limits the value you get out of any automation.

  3. Hello people,

    We are trying to implement Selenium+Java to automate Siebel 8.1.14 Open UI, but as you have noticed, the attributes of the objects that are used(ID, Name) is system generated based on different responsibilities(Views and Responsibilities) and Market customization. How can we tackle this issue?

    Kindly Help

  4. Hi Hemraj,

    If you plan to interact with controls on the Siebel UI, it'd be best to go through the Siebel OUI API. For elements that require direct DOM access, try to externalize the reference, because I can guarantee that they will change =)

  5. Hello Jason,

    Thanks for the quick reponse.. really appreciate.. :) We are dealing with Siebel Application for 40 different markets, in other words 40 different SRFs and Object Managers and 40 different customizations. By your experience, do you advise to use selenium for automation? As you might has guessed, the same automation script should run for 40 different environments and as discussed earlier, the attributes WILL change and thus it will fail. If you think we can carry on, a small elaboration in your part will be highly appreciated,.. :)

    Thanks in Advance Jason


  6. Hi Hemraj

    Selenium is an enabler to control OUI, but remember this is a bespoke approach, so a lot depends on how advanced your automation capabilities are, and how much you want to automate. The approach described above was used to perform WCAG validation, and navigate through a simple TBUI interaction. The key is to create a library to interface with OUI and its API, but its hard to elaborate beyond that on this forum, without understanding the design of your program, and your particular challenges. Its best to seek the services of a SME that can provide more localised advice.

    Good luck


Comments are open to all, please make it constructive.