Testing is very important for data warehouse systems to make them work correctly and efficiently. There are three basic levels of testing performed on a data warehouse −
In unit testing, each component is separately tested.
Each module, i.e., procedure, program, SQL Script, Unix shell is tested.
This test is performed by the developer.
In integration testing, the various modules of the application are brought together and then tested against the number of inputs.
It is performed to test whether the various components do well after integration.
In system testing, the whole data warehouse application is tested together.
The purpose of system testing is to check whether the entire system works correctly together or not.
System testing is performed by the testing team.
Since the size of the whole data warehouse is very large, it is usually possible to perform minimal system testing before the test plan can be enacted.
First of all, the test schedule is created in the process of developing the test plan. In this schedule, we predict the estimated time required for the testing of the entire data warehouse system.
There are different methodologies available to create a test schedule, but none of them are perfect because the data warehouse is very complex and large. Also the data warehouse system is evolving in nature. One may face the following issues while creating a test schedule −
A simple problem may have a large size of query that can take a day or more to complete, i.e., the query does not complete in a desired time scale.
There may be hardware failures such as losing a disk or human errors such as accidentally deleting a table or overwriting a large table.
Note − Due to the above-mentioned difficulties, it is recommended to always double the amount of time you would normally allow for testing.
Testing the backup recovery strategy is extremely important. Here is the list of scenarios for which this testing is needed −
There are a number of aspects that need to be tested. These aspects are listed below.
Security − A separate security document is required for security testing. This document contains a list of disallowed operations and devising tests for each.
Scheduler − Scheduling software is required to control the daily operations of a data warehouse. It needs to be tested during system testing. The scheduling software requires an interface with the data warehouse, which will need the scheduler to control overnight processing and the management of aggregations.
Disk Configuration. − Disk configuration also needs to be tested to identify I/O bottlenecks. The test should be performed with multiple times with different settings.
Management Tools. − It is required to test all the management tools during system testing. Here is the list of tools that need to be tested.
The database is tested in the following three ways −
Testing the database manager and monitoring tools − To test the database manager and the monitoring tools, they should be used in the creation, running, and management of test database.
Testing database features − Here is the list of features that we have to test −
Querying in parallel
Create index in parallel
Data load in parallel
Testing database performance − Query execution plays a very important role in data warehouse performance measures. There are sets of fixed queries that need to be run regularly and they should be tested. To test ad hoc queries, one should go through the user requirement document and understand the business completely. Take time to test the most awkward queries that the business is likely to ask against different index and aggregation strategies.
All the managers should be integrated correctly and work in order to ensure that the end-to-end load, index, aggregate and queries work as per the expectations.
Each function of each manager should work correctly
It is also necessary to test the application over a period of time.
Week end and month-end tasks should also be tested.
The aim of system test is to test all of the following areas −
Note − The most important point is to test the scalability. Failure to do so will leave us a system design that does not work when the system grows.