Showing posts with label regression testing. Show all posts
Showing posts with label regression testing. Show all posts

Wednesday, July 7, 2010

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...

Friday, June 18, 2010

Effective Regression Testing for OBIEE Applications

It's a dark and stormy Friday night, and as you drift off into slumberland in your warm, dry and cozy bed, a thought pops up in your mind: "If a butterfly flaps its wings in Costa Rica tonight, will the CFO's Executive Financial Summary dashboard still work?" Suddenly you are wide awake and feeling a bit of paranoia. You jump out of bed, fire up your laptop, log into the corporate VPN and then into OBIEE...

This sounds like the beginning of a bad BI horror story -- and hopefully for all of you a scenario like this truly is just that - a story. But we've all experienced some variation of this scene. The OBIEE equivalent of butterflies do flap their wings in Costa Rica, and the result does sometimes alter the OBIEE equivalent of weather patterns in Japan. Change the name of a presentation column... or the mapping rules of a logical column... or the aggregation rules of a logical table... or a minor extraction rule in the warehouse ETL logic... or even simply merge your local RPD work into a MUD repository... and you risk causing an error in a report that might not be noticed until days after the change -- usually when the report is most needed.

The real truth is that an OBIEE system just like any other software implementation has some inherent fragility that requires vigorous regression testing strategies to keep it running smoothly. But while most "traditional" software systems have very clearly defined behaviors that lend themselves well to control by means of various specific testing strategies, a Business Intelligence application by nature does not always necessarily have completely predictable outcomes - especially true in OBIEE given the complexity of the BI Server and, for example, how it constructs queries against the underlying data.

Given the complexity of the OBIEE architecture and the fleeting nature of the data, establishing an adequate regression testing strategy is a challenge.

One excellent approach is to identify commonly executed queries with Usage Tracking (or just identify a specific request's logical query), then execute the corresponding logical sql using nqcmd.exe. This is an excellent approach but can respond to only two results: success or failure. In most cases this is entirely adequate.

Another approach favored of course by Oracle is to implement their Application Testing Suite, which looks ike a promising tool but frankly I have not heard of any usage in the real world -- if anyone has direct experience with this tool, feel free to respond. Moreover it goes without saying that license fees would be a significant factor in evaluating its total ROI.

A third way to address regression testing in OBIEE is to set up a series of webcat (HTTP) requests that can be executed on a scheduled basis by an automated web testing utility. Several such utilities exist - LoadRunner being the most prevalent - but as with Oracle's offering, most require licensing.

One popular web testing utility distributed as open-source software and therefore free of licensing costs has gained some following among the developer community: a Firefox plugin called Selenium (the IDE flavor, to be precise), which can execute a wide range of web page interactions and combine them into test scripts. These test scripts can then be assembled into test suites and exported to a full-fledged program in a variety of commonly used languages/frameworks (C#, Java, Perl, PHP, Python, Ruby), at which point this program can be scheduled for execution just like any other.

While Selenium is highly flexible, fairly easy to use and very cheap (at least in terms of licensing costs), it also has some drawbacks, particularly when used to test an OBIEE system. In the hopes of blazing the "Selenium for OBIEE" trail, I have attempted my own small POC by writing some basic test scripts against the Paint webcat. In doing so I identified some gotchas and workarounds that will at the very least help you successfully construct OBIEE test scripts using this very capable tool. I will explore those workarounds and advanced configurations in later posts. But my overall opinion is that Selenium is a very capable testing tool which deserves serious consideration for use in an OBIEE environment.

Here are what I consider general strengths of Selenium:

Flexible
  • Can execute a variety of actions: open urls, click links, interact with prompts, execute javascript ...
  • Can be designed to respond to specified conditions either by failing OR by simply logging and continuing
  • Can assemble multiple test scripts within a single test suite
  • Can export scripts in a variety of languages / platforms - C#, Java, Perl, PHP, Python, Ruby
Straightforward to use
  • Scripts can be written using a simple Firefox plugin
  • Applies open standards: page elements are identified using Xpath
Economical
  • Open Source therefore no licensing
  • Fairly wide adoption therefore a decent user community
  • Commercial organizations exist that specialize in Selenium development & support
And some general challenges:

Somewhat steep learning curve
  • Though basic use is straightforwad, still takes a bit to get the hang of the tool
  • Because it's based on open standards like XPath, the skills learned are not "siloed" but can be useful elsewhere
  • Extending test suites for scheduled execution requires a leap of additional complexity
Open Source = No official support
  • On the other hand, there are plenty of answers to common problems on the web
  • Googling a solution is probably just as fast as relying on traditional paid support
OBIEE-Specific Challenges
  • Problematic handling of daughter or "target" windows
  • Default page element XPath queries cannot be used because they rely on IDs, which in OBIEE are dynamic