Blog Archives

Testing Presentation from the 2013 BIWA Summit

I thought I’d post my presentation on QA (testing) that I delivered this week at the BIWA Summit near Oracle HQ in California. The preso is based off of the recent QA posts I did, with a bit more silly graphics on top of it.  The one take away from the preso is that some people prefer the term testing as opposed to QA.  Good to know.  Anyway, enjoy!

KPI Run Your QA Cycles More Effectively

BTW, the event focused heavily on the future of BI and Data Warehousing.  Essentially, whatever we are doing now is going to radically change to include many new types of data from different places and sources, plus what kinds of analysis we do will also be greatly enhanced.  OBI is layering on top of a whole plethora of Oracle’s Analytical technologies, including: Essbase, EPM, HCM, OLAP, RTD,  Endeca and R.  The OBI server or UI will have hooks into just about everything you can think of, making some advanced capabilities available to dashboard users.  We’ll see how it actually plays out, but in the future some pretty heavy stuff will be available in the dashboard.

Next up is a presentation on Performance Tuning the BI Apps which I’ll be delivering at KScope in June in New Orleans and Collaborate in April in Denver.


QA for OBI (Part 2 – The Tests)

In the last post I discussed some general, overall topics to prepare you for a better QA cycle.  In this post I’d like to get into the details a bit more to discuss some of the actual tests you can perform across both ETL and OBI layers.  In particular I’m going to focus on data testing for ETL and OBI.

Read the rest of this entry

QA for OBI (Part 1 – Planning)

It seems that every client and every project (I think I’m in the 40’s now) has a different way of QA’ing their OBI system.  This holds true for whether you are doing a BI Apps deployment or simply a new deployment of a custom solution.  This post will set the foundation for the discussion of what needs to be QA’d and how to break the multi-layered solution into more manageable units.

I get the feeling sometimes that my customers are expecting QA to be something perfectly pre-canned that I can simply show up with, fill in the cells in a spreadsheet, and off we go.  The reality is that each project by nature is different, starting from a different place, executed in a different manner, and with different people involved.  It follows that some of the specifics of the QA cycle will therefore be different as well.

Read the rest of this entry