Database Reference
In-Depth Information
Testing the Solution
Testing the solution is much like editing a book. The tester must understand the basic look and feel of the
content, verify that the information presented is accurate in a format prescribed by the business requirements
and confirm that the end product has not deviated too far from its original specification. Having someone edit
your work is always preferable to doing your own editing, because it is quite easy for you to overlook mistakes in
your own work.
As a developer, you can help this process with documentation and consistency. These tools play a major part
in making any solution easy to review and validate. The Excel spreadsheet in Figure
2-2
, for example, can be used
to document the data source columns and data destination columns for testing purposes. Using this, the tester
can verify that the column names, data types, and transformations outlined in the Excel spreadsheet are the same
at the end of the project as they were at the beginning.
Any deviations from this plan can be questioned, and responses to why the deviation occurred can be
answered. These answers are recorded in hopes that the changes created during the first iteration can be
anticipated in the next step of the BI solution.
We delve deeper into the details of how to test a BI solution in Chapter 18.
Approve, Release, and Prepare
At the end of the BI solution is a formal approval process. During this phase it is important to review whatever
changes are found during the testing process and to document an evaluation of the findings. Typically this
document is in the form of a Microsoft Word document that describes, in paragraph form, the various aspects of
the individual projects that were included in the BI solution.
It does not have to be very long nor does it have to read like a literary novel. It should simply state the facts so
that you can plan the next version of the solution using knowledge gleaned from the previous version. Once this
is presentable, you can release the solution to the client. You may need to draft a user manual to be released at
the same time. At this point, it is a good idea to gather feedback from the users.
Although there will always be another “final” version, eventually you will come to a place where a new final
version will not happen nearly as frequently. Therefore, you should always plan for the version of the BI solution
you are releasing to be transitory so that it can be improved upon through experience gained and through user's
feedback. We discuss this process further in Chapter 18.
Moving On
In this chapter, we discussed how to create a BI solution from start to finish. We started by examining the
requirements and identifying the data, and then we moved on to planning the BI solution using simple
documentation. Next, we built a data warehouse in SQL Server, filled it with data using Integration Services,
created a cube with Analysis Services, and made a report with Reporting Services.
Now we restart at the beginning with an in-depth look at planning your BI solution in the next chapter.
What's Next?
There are many ways to create a BI solution. Learning about other methods will supply you with additional tools
to customize the steps we have laid out here to match those in your organization. We recommend the following
book as a good place to start:
Delivering Business Intelligence with Microsoft SQL Server 2012
by Brian Larson
(McGraw-Hill Osborne).
