Testing Relational Database

Overview Once the design of a database system has been completed, the developers are ready to move into the implementation phase of the development. Implementation includes all the tasks that are necessary to covert from the old system to the new system. A common mistake is for people to think that implementation simply involves the creation of electronic files and installing new computer systems. In fact, much of the work involved in the implementation of a system is carried out away from computers. Full implementation of a database system that supports a large information system means taking the design work, converting it into electronic files, preparing staff for the introduction of the new system, testing the system to make sure that it is fully functional and completing an evaluation of the system. At a later stage, it may be necessary to carry out maintenance on the system in order to make improvements to it or adapt it in some way.

Overview In this topic, we will look briefly at each of the following activities: Creation of Test Plan Database Development Database Testing Creation of Documentation System Conversion Post Implementation Review Maintenance

Creation of Test Plan A carefully produced test plan is essential. The test plan is created before the system is produced. It shows: What elements of the system are going to be tested What types of testing will be carried out What test data values will be used to test the system

Creation of Test Plan The purpose of database testing is to ensure reliability of the system. Reliability generally increases with the amount of testing that is carried out. Given its importance in determining the overall quality of the product that is delivered to the client, database testing is a process that must follow a pattern and well-defined plan. Once the plan has been defined and the system produced, the actual testing is often carried out by an independent test group to help ensure a high-quality, highly reliable solution. Testing, however, can never demonstrate that a system is totally reliable: it can only show the presence of errors, not prove their absence. It is always possible that undetected errors may exist even after the most comprehensive and rigorous testing is performed.

Contents of Test Plan The test plan will be used by the development team, independent test group, clients and end users of the system to make sure that the system is functioning correctly and reliably. The test plan must indicate: What elements of the system are to be tested; What types of testing are to be carried out; The order in which the testing will be completed; Test data values that will be used to test the system.

Elements to be tested A complex database system will consist of a number of separate elements. Some of the elements can stand alone whilst others are linked to other elements within the system. The test plan must indicate not only which of the elements of the database are to be tested but also how they are to be tested. The elements of a database system that are likely to be included in any test plan for a database system include: Tables Relationships Queries Forms Reports User interface Scripts

Types of Testing Since a database system consists of a number of individual and related elements, different types of testing are used to test different aspects of the system. The types of testing that must be considered in the test plan are: Component testing Integrative testing Systems testing Acceptance testing

Component Testing Component testing is the process of testing the smallest, individual units in the system before they are put together to form a whole system. Component testing often takes place alongside the database development work that is carried out during the implementation phase. As soon as an individual component has been created, it is tested in isolation. Component testing focuses on individual units or modules, independently of all other components. This enables the tester to detect errors that result from within that module alone. Any errors that result from interaction between modules do not therefore arise. Component testing is the purest form of white box testing. To carry out successful component testing, the internal workings of the component must be fully understood. Tests are carried out to make sure that the internal operation of the module performs according to its process specification. The test data values used for component testing are designed to uncover errors within the boundary of the module. The values should be selected carefully to test each condition and option fully.

Elements tested in Component Testing Individual elements of a database system that are likely to require component testing include: Tables Queries Forms Reports Scripts

Integrative Testing Integrative testing is performed by combining components in steps. While component testing concentrates on specific units and modules, integrative testing is performed on a hierarchy of components, especially on interfaces and boundaries between them. If components work alone, why won't they work when combined? Because integrating components may develop the following errors: Data can be lost across interfaces or boundaries A component may not perform as well as expected when combined with another component One component may have an adverse affect on another Integrative testing follows on from component testing. Component testing tests a single module that is subjected to appropriate test data values. Once the testing of this component produces satisfactory tests results, a second component is introduced, and more test cases are applied. The process continues until all the components are eventually integrated into a complete system. Because of the incremental nature of this approach, it can be assumed that if errors occur when a new component is introduced, those errors are caused by the addition of the new component, or some aspect of introducing it. The source of errors is therefore localised making it easier to detect and correct errors.

Integrative Testing Integrative testing does not test the complete system as a whole. Instead, it concentrates on the integration of the various components in the system. The main concern is the compatibility of the individual components. Testers are trying to find areas where linked components have been designed with different specifications for data length, type and data element name. For example, one component may expect the data item for customer code to be a numeric field, while other components expect it to be a character item.

Elements tested in Integrative Testing Elements of a database system that are likely to require integrative testing include: Relationships Forms Reports User Interface Scripts Suitable candidates for integrative testing would include any elements of a database system that requires data to flow from one component to another.

System Testing Systems testing is the process of testing the fully integrated components of the database in the context of the complete system that it supports. Tests carried out at this level are designed to ensure that the system meets all of the requirements listed in the system specification. This type of testing requires knowledge of the functions that a system is supposed to perform. Tests are carried out to make sure that each function is fully operational and reliable. Systems testing is an example of black box testing. Black box testing demonstrates that functions within the system are operational, that output is correctly produced from input provided, and that database structures are properly accessed and updated. It requires knowledge of the system's requirements to conduct such tests. Black box testing therefore does not examine the internal structure of the system.

System Testing Test data values used for systems testing consist of sets of input conditions, either intentionally valid or invalid, that fully exercise all functional requirements of the system. Systems testing tends to be carried out during the later stages of testing. Since it focuses on the function of the system as a whole rather than concentrating on the components within the system, systems testing cannot take place until the database has been fully developed.

Acceptance Testing Acceptance testing evaluates the new database system to determine whether or not it meets user requirements under operating conditions. When the system and its documentation are deemed suitable by the development team, it its time to release the system to client and/or user group to get feedback. A user group should be composed of all or a sample of the people who will work with the system once it is fully developed. Acceptance testing is the last chance to test and rethink things before the database is converted from a development project into an operational system.

Acceptance Testing Acceptance testing is carried out by clients and end users of the system. Members of the development team may be asked to observe the acceptance testing so that they can see for themselves any problems or difficulties that arise. If the development team do not observe the acceptance testing, they must be provided with feedback from the group of users working with the system. Users would be expected to record details of any problems, real or imagined, encountered during acceptance testing and report them to the development team periodically. Any necessary modifications must be made to the system prior to its release for full implementation and operations.

Types of Test Data There are three very different types of test data values that should be used to fully test a database system: Normal values Extreme values Exceptional values Test data values are selected with the express intent of determining whether or not the system processes them correctly. Each set of test data values is designed to test how the system copes with the values when they are entered. The developers must make a note of any output that they expect to be generated when the test values are actually used with the system. This is an important aspect of a test plan. Without a record of what is expected to happen when testing takes place, the testers will have nothing to compare the actual output produced by the system with. When actual output from testing is compared with expected output, it is easy to identify when processing errors have occurred. Only after the sets of test data been selected and expected outputs have produced, can the system be tested with these test data values and test results are generated.