Database Reference
In-Depth Information
solution is lost because of validation errors, it is difficult if not impossible to regain. so, the cost of not testing
may be much higher than you think!
Objective Verification
Objective verification is possible only if the objectives of the BI solution have been clearly defined. In a
perfect world, the development process clearly identifies the goals at the beginning of the BI solution. In
reality, documentation will likely be rather sketchy and incomplete. Most team members realize that good
documentation will make the test teams' job that much more effective, but time and resources can limit the
chances of this ever taking place.
As the versions of your BI solution progress, lessons are learned, and the documentation is likely to be
improved upon. This is a management task that needs to be identified and coordinated to be successful.
One effective way to create good documentation is to add one or more technical writers to the team to
help manage and improve the documentation process. Tech writers are invaluable on larger solutions, but even
smaller solutions can benefit from their expertise. Some companies hire freelance technical writers for smaller
solutions to help keep costs down.
Here are some helpful suggestions to keep consistency and verify objectives:
•
Create a standard template for documentation.
•
Make sure the standard template is easy to follow.
•
Make sure the standard template does not take long to complete.
•
Make sure that developers update the documents with lessons learned.
•
Have testers review the documentation before implementation begins, where possible.
•
Have a professional technical writer review and enhance the documentation.
Improvement Identification
A design may look good in print, but after implementation, it may not be nearly so wonderful. From our building
construction analogy, we implied that an experienced builder may have input into the construction that could
improve the building. Over time you would expect an architect to become better at designing buildings based
upon input from experienced builders, but of course that will not happen if the architect does not receive
feedback from the builder.
The same goes for developers who never hear feedback from the test team. Often, the developers have
already begun working on the next version by the time all the components of the current BI solution have
been assembled and placed into the hands of the test team or even the end users. Therefore, it is important to
provide a way for testers and users to report their recommendations to the developer in a manner that makes the
information readily accessible at any time during the development process.
In our experience, creating a web application that allows users and testers to enter recommendations is
helpful since they can be reviewed by developers at any time. The problem with this approach is that much of the
feedback may be redundant and ill defined. Assigning someone to moderate the input can reduce these problems.
Another simplistic way to get feedback is to set up an email account such as suggestions@MyCompany.com.
Like the web page approach, the information should be managed to improve effectiveness.
All of this can be time-consuming and costly, but be aware that a company that lacks a mechanism for
capturing recommendations can often be seen as arrogant or even hostile to both users and testers.
To combat this, we recommend conveying what feedback has been received, anonymity as to who is giving
the feedback, and transparency in disclosing what is being done about it.
