| Developing a meta data repository can be as complicated as developing any other application. Therefore, the same structured development guidelines should be followed, particularly the testing guidelines. While most business managers and information technology (IT) managers demand quality in their applications, they often do not want to spend much time on testing. That does not work! In addition, many project managers constantly underestimate how long testing will take, and they do not allocate sufficient time for testing in the project plan. What is worse , when milestones are missed, the short time originally planned for testing is reduced further. The point is that you must schedule sufficient time for meta data repository testing and reflect it in the project plan. In addition, plan to have a sufficient number of testers available at the appropriate time. Fortunately, testing is one of the few activities that can easily be modularized, and adding more testers will speed up the testing effort.  | Experience has shown that for every day of coding, you should plan three days of testing. | | Of the various types of testing discussed in Step 11, ETL Development (unit testing, integration testing, regression testing, performance testing, quality assurance [QA] testing, and acceptance testing), only four types of testing are usually required for a meta data repository, as shown in Table 14.1. -
Unit testing for meta data repository programs is no different from unit testing for other types of application programs. The programs must compile without error; they must perform their functions according to the program specifications; and they must include the appropriate edit checks. Table 14.1. Required Testing for a Meta Data Repository | Unit testing | Does the code compile without errors? | | Integration testing | Do the deliverables meet the requirements? | | Regression testing | Did the changes to the program cause damage to this or any other program? | | Acceptance testing | Are all aspects of the deliverable acceptable? | -
Integration testing, sometimes referred to as system testing, verifies that the original objectives of the meta data application are being met and that all meta data repository functions perform as expected. Integration testing should include the initial population of the meta data repository, periodic or intermittent updates to it, the access interface process, the tool interface process, scheduled reports , canned queries, and the online help function. This test is carried out according to a test plan (described in Step 11, ETL Development), and the test cases are run by testers rather than by the developers of the code. (Developers can test other developers' code, just not their own.) -
Regression testing is performed on different versions of the same software, which can be produced during the development cycle within one project or when the same software is revised during different subsequent projects. Each time changes are made anywhere in the existing programs, a full regression test cycle should be run to ensure that the changes did not inadvertently break some programming logic downstream in the program or somewhere in the entire stream of programs. Regression testing is a formal test activity and must be performed with a test plan. Since a complete meta data repository will probably not be built all at once but over time, regression testing is an important part of all projects that enhance the meta data repository. -
Acceptance testing is even more important than the other forms of testing. This test determines whether the meta data repository (new or enhanced) is ready to be rolled out. This final testing process for the meta data repository usually combines QA testing and acceptance testing. The business people and the technicians who will be using and supporting the meta data repository are involved in this testing. Similar to integration testing and regression testing, this test is executed with a test plan, predefined test cases, and expected test results; all test runs are documented in the test log.  |
