Database Reference
In-Depth Information
Chapter 18
Testing and Tuning BI Solutions
Why, a four-year-old child could understand this report. Run out and find me a four-year-old
child. I can't make head nor tail out of it.
—Groucho Marx
As you have seen thus far, the purpose of this topic is to introduce concepts and practices that are commonly
found in BI solutions. We have organized the process of creating a BI solution into eight steps and we are finally
approaching the end of these. The practice of testing and tuning constitutes the next step in our process. This
arguably is the most important step, because a BI solution is worthless if it is not functioning properly.
We begin by ascertaining what testing and tuning mean, in regards to a BI solution. Although there is no
simple answer, it is important to analyze the basic objectives involved with this process. For testing, our goal
is to validate the current solution through objective verification. For tuning, our goal is to provide possibilities
for enhancements by benchmarking the current performance, identifying poorly performing components, and
recommending improvements.
Although each objective is slightly different, they are complementary. In this chapter, we examine testing
and tuning examples and discuss how these subjects supplement your BI solution.
Testing the BI Solution
Testing the BI solution involves documenting what the BI solution should contain, verifying that those items
exist, and identifying possible areas of improvement.
When we began our example BI solution, we determined its contents using an Excel spreadsheet. Now that
the solution has been created, we could pass the Excel spreadsheet onto the test team for validation. The test
team would then go through each individual column, attribute, or configuration noted in the documentation and
verify that what was planned has indeed been implemented.
Testing is an important part of a BI solution, but unfortunately it is also one that is all too often overlooked.
To give perspective to its relevance let's consider an analogy.
Consider the construction industry. Before building inspectors became common, the quality of buildings
and homes depended upon the builder rather than the original architect. If the builder did not follow the
architectural blueprints correctly, the building might be unsafe. Of course, this would not always be true; expert
builders could actually improve upon the architecture. Unfortunately, the unsafe outcome was common enough
that most cities and states adopted the use of building inspectors to ensure that houses and office buildings were
built to the specifications of the architect.
A tester is like a building inspector who provides a mechanism for ensuring the quality of whatever software
you create. Their job, like the building inspector, is to review the blueprints and identify inconsistencies and faults.
