Using Selenium for OBIEE Regression Testing

In my last post I introduced Selenium, an open-source testing platform with an easy-to-use Firefox plugin that can be used as a cost-effective tool for regression testing web-based applications like OBIEE. I promised to demonstrate workaround to OBIEE-specific challenges when using Selenium, namely:

• Selenium's problematic handling of daughter or "target" windows, and
• Dynamic element ID generation in OBIEE
  

[Note: All examples given here will be executed against the Paint demo installation using Firefox 3.5.10, which according to Oracle Support is the most recent version of Firefox that is supported in the most recent version of OBIEE (10.1.3.4.1)]

Here's a common scenario impacted by these challenges: When configuring a Dashboard to link to another Dashboard, OBIEE would open the new Dashboard in a "daughter" or "target" window.

Selenium would have trouble scripting this behavior because a) the only way Selenium can effectively identify target windows is by element ID (this is a known issue that doesn't appear to have a resolution from the Selenium project forthcoming anytime soon - though, in the grand tradition of Open Source software, you are welcome to figure out your own fix!) and b) OBIEE generates element ID's dynamically, which means they will change with each instance of the Presentation Server. So any Selenium-generated script would not work against a different Presentation Server, or against the same Presentation Server after a restart.

To illustrate the problem more clearly, I will create links to Dashboard pages in "My Dashboard." In this example I created links to "Brand Analysis", "Regional Analysis" and "Year over Year Analysis".


As you know, clicking into any of these links opens a new window (whose name = "_blank") to display the selected dashboard.

The workaround solution to this problem: 1) identify the URL that is opened in the "_blank" window, then 2) execute a standard Selenium "Open" command on that URL.

The key is the first step: identifying the URL of the "_blank" window. Doing so involves two tricks: a) Identifying the desired <A> element using XPath (which is an open standard that Selenium relies on to identify & interact with page elements); then b) identifying its HREF attribute.

If you're not familiar with XPath, it may be helpful to take a look at the following sites first, each of which offer a concise one-page explanation of XPath basics:

• XPath Syntax
  http://www.w3schools.com/xpath/xpath_syntax.asp
  
  
• How XPath Works
  http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JAXPXSLT3.html
  

Let's take a look at the html for the customized "My Dashbaord" to understand some essential XPath concepts.

<a
   href = "saw.dll?PortalPages[...]Done=Close"
   target = "_blank"
   name = "SectionElements">
   <span
      class="NavLinkCaption">
      Brand Analysis
   </span>
   </a>

The "attributes" of the <a> tag (or "Element") are "href", "target" and "name". Their respective values are 'saw.dll?PortalPages[...]Done=Close', '_blank', and 'SectionElements'.

The "attribute" of the <span> element is "class" and its value is 'NavLinkCaption".

The "child" of the <a> element is the <span> element. Or put another way, the <a> element is the "parent" of the <span> element.

The <span> element content "contains" the text 'Brand Analysis'.

Using XPath there are several ways to identify an element, but not all can be used with web pages created in OBIEE:

• Element ID - Usually the best approach, and is the default behavior in Selenium, however this approach is not possible because OBIEE generates element ID's dynamically
• Ordered location in the document - Not advisable because any change in document content (e.g., adding a new <a> tag before the desired <a> tag) may break the XPath query
• Attribute (href, target, name, etc) - Not possible because OBIEE attributes are not unique; there are several href's whose target = "_blank" or name = "SectionElements"
• Displayed content - The best bet for OBIEE, since displayed content will be unique by definition (how else could the user differentiate between the links?)
  

To identify the desired <a> element via the contents of the <span> element, we can use the XPath "contains()" predicate:

//a/span[contains(.,'Brand Analysis')]

Pseudo-SQL translation: Select span.* from document where span.parent = <a> and span.content like '%Brand Analysis%'

Then the ".." expression (meaning "Parent of") can be used to identify the desired <a> tag, which is the parent of the <span> tag we identified above.

//a/span[contains(.,'Brand Analysis')]/..

Pseudo-SQL translation: Select span.parent from document where span.parent = <a> and span.content like '%Brand Analysis%'

Now we're going to use this XPath path expression to create two Selenium test case steps -- one which uses the Selenium saveAttribute command to assign the value of the <a> tag's href to a variable named 'windowURL', and another which opens that URL within the current window:

[Background: Selenium steps consist of three components: Command, Target and Value - For full documentation of Selenium's functionality see its official site: http://seleniumhq.org/docs]

Step 1:
Command: storeAttribute
Target: //a/span[contains(.,'Brand Analysis')]/..@href
Value: windowURL

Step 2:
Command: open
Target: ${windowURL}
Value: [blank]

Here's how the commands would look like in Selenium:


There are many more aspects to Selenium integration with OBIEE to learn that I hope to touch on in subsequent posts - but this little tutorial should give you a good start.

Have fun...

BI and the Tools of Diplomacy: Summits and Treaties

In my last post I explored the importance of language & communication in diplomacy and, by extension, the BI practice. In this post I'd like to consider two more tools of diplomacy and how they can be applied to the BI practice.

The Summit

A Summit provides a forum where all sides have the opportunity to speak directly with each other in a highly focused and most importantly, face-to-face format. In today's business environment it is too easy to fall victim to the limitations of email, telephone or even video communications. Even with the best video conference, few mediums of communication replace the extraordinarily "high bandwidth" of physical presence. (As an example within BI Consulting Group's experience, read my colleague Ed Martin's recent post reporting on our company-wide Summit held last week in Minneapolis.)

But common focus is also important. Well-organized summits often have a stated purpose agreed upon by all participants before or immediately at commencement. Sometimes ground rules even require that participants not leave until specified goals are met (think the Catholic Church's "White Smoke" summit -- or Conclave -- of Cardinals that elects a new Pope).

Of course a typical run-of-the-mill business meeting is a similar exercise... But when signficant, concrete progress must be made between parties of disparate backgrounds, framing the discussion in the specific terms of a Summit can be an effective way of setting the stage for the quality of interactions that will ensue.

The Treaty

The ultimate formal goal of any diplomatic effort is the execution of an agreement between all parties that sets specific parameters for behavior. The most obvious parallels in the BI practice are requirements documents, functional specs and service level agreements. In each case, the agreement clearly specifies the "rules" under which the signatories are required to behave.

In BI of course, one of the actors is the technology itself. In a Treaty, individual countries are held accountable for the performance of their borders, regulations and tarriff; in a Service Level Agreement, the IT support staff is accountable for the timely and stable operations of servers and applications. Well-written Treaties, SLAs and really any legal contract are useful to all signatories because they clearly define the expected performance of each participant and actions to be taken when that performance is breached. But the key concept is "well-written" -- a good agreement is clear and specific but not so obtuse that a lawyer is needed to interpret it.

An important component of an effective BI "Treaty" is the data validation report. A good BI implementation will include data audit reports -- confirmed as authoritative by all parties -- that compare warehoused data against source transactional data. These audit reports serve as the arbiters of performance that determine objectively and decisively whether the warehouse (in the "Tech Nation") is holding up its end of the Treaty by correctly reflecting source data (coming from the "Business Nation").

I plan to explore more tools of diplomacy in posts to come (trying to work "the Spy" into this discussion!), but as usual, in the meantime I'd love to hear your feedback and especially any other examples of Treaties and Summits in the BI practice.

The United Nations of Business Intelligence

I find many aspects of my work very fulfilling and many ways I am proud of my job. However, one of the least pleasant is the industry-standard title ascribed to the role I typically play in a BI implementation: "Business Analyst." It's probably one of the most understated job titles of all time and worse, the ultimate cocktail party conversation non-starter. Who invented the term anyway? It's stupid and I'm tired of it.

Of course the natural response would be: "You may have a point but what else would you call it?" Indeed, how else would you name this role, which by its nature has no traditional "profession" of its own but instead straddles a kind of no-man's-land between professions -- that of clients (who need the assistance of technologists to achieve business objectives) and of technologists (who perform the work required by the client)? And how to come up with something sexy to boot?

Meeting with an old college friend years ago, I tried laboriously to explain the nature of my work in the glow of a second glass of Zinfandel (or was it a third?). My friend asked me an intriguing question: Did my professional endeavor in IT have any relationship to my undergraduate experience? At the time I was over ten years out of college and a bachelor's degree in Foreign Service (aka International Relations) -- and 9/11 was still raw in my mind, so I was bemoaning the fact that I chose to pursue opportunities in software development rather than diplomacy. But, perhaps thanks to that same glow from the wine, I took a look at my job from a different angle and saw something very interesting: The IT roles that I had performed often involved a certain degree of, shall we say, mediation. Thinking it through, I realized something more fundamental: while performing various IT roles, I often perceived an acute need for mediation between the "suits" and "geeks" and I found myself drawn into fulfilling that need, partly because I liked doing it but largely because my skills were well-suited to that role.

From that point on I began to see more clearly the importance of the mediator in successful IT endeavors. Over time I have also come to believe that this role has much in common with the practice of diplomacy -- particularly within the specific discipline of Business Intelligence, where interactions between clients and technologists become uniquely more intense than in a typical IT project.

What I'd like to do first is explain the parallels I see between diplomacy and the role of the classic IT Business Analyst. Then I will take the next logical step: to explore what lessons from traditional diplomacy we can apply to the practice of Business Intelligence in particular. Hopefully I'll shine a fresh light on this important role and perhaps even inspire somoene to devise a job title that's far more sexy than "Business Analyst."

Traditional Diplomacy and the Traditional Business Analyst

In traditional diplomacy, the diplomat mediates between what I'll call "physical" nations: the US and China, for instance. A BA does essentially the same thing - but between "metaphorical" nations: the client (aka "The Business") and the technologists (aka "IT" or "Tech"). Let's consider some hypothetical characteristics of physical nations and their parallel among metaphorical nations: [Please understand that my examples are sometimes oversimplified generalities intended purely to illustrate the point and not pass value judgements on any country or group of people]

	Physical	Metaphorical
Goals / interests / agenda	US: Increase industrial production; decrease cost of healthcare; decrease energy demand; promoting the global spread of democracy China: Increase industrial production; increase citizen wealth; increase energy supply; promoting the harmony of Chinese society	Tech: Work with cutting-edge technology and phase out old technology; build resumes Business: Increase [revenue / profit], decrease costs, build resumes
Language	US: English China: Mandarin	Tech: SQL, Java, HTTP, SOA, "geek speak" Business: Quarterly financial statements, Balance sheet accounting, "corporate speak"
Natural resources	US: Wheat, coal, consumers, Hollywood China: Cheap and abundant labor, cash	Tech: CPUs, RAM, computational thinking, technical skills, hard work, creativity Business: Money, market-oriented thinking, business skills, hard work, creativity
Cultural values	US: Individualism China: Collectivism	Tech: Collaboration Business: Competition
Currency	US: Dollar China: Yuan	Tech: Game rooms, private office space, logo wear, money Business: Titles, adminstrative assistants, corner offices, money
Fashion	US: T-shirt & jeans, Little Black Dress China: Mao suit, qipao	Tech: Logowear, boardshorts, Tevas Business: Business casual, suits

Despite the oversimplifications, the parallels are compelling.

Given this common concept of a "nation," let's consider the professional challenge of the traditional diplomat:

How to foster a trusting and productive relationship between his employer's nation and other nations (at least, those that his employer considers important)...
So that his employer's nation can effectively apply its unique natural resources to pursue & fulfill its own agenda...
And the citizens of his employer's nation can be happy and prosperous.

In comparison, the challenge of the Business Analyst is basically the same but with notable differences:

How to foster a trusting and productive relationship between ALL nations...
So that ALL nations can effectively apply their unique natural resources to pursue & fulfill their agendas...
And the citizens of ALL nations can be happy and prosperous

The Business Analyst is in the unique position of being required to ensure that the interests of all nations are being satisfied. This mission is more akin to that of the United Nations Secretary General -- which is also not an easy job but I'm sure Ban Ki-Moon has an easier time at cocktail parties. And the chauffeur would be nice too.

In my experience this perspective has proven to be a useful way to understand and manage the dynamics of interactions between IT and "The Business." For my next post I will consider some specific tools and techniques of traditional diplomacy and how to apply them to a Business Intelligence practice.