Software has been produced for over half a century now. It is kind of
the soul of a computer, and basically all firms and institutions rely
on their computers. They control atomic power plants, most countries
defense systems, and our whole financial market would not work without
them. This and the fact that more than one ``Pfennig'' of each ``Mark''
spent in Germany is used for software development make
it very surprising that the field of software quality assuring
and software testing has basically been
ignored by most universities and similar educational
institutions. This is slowly changing now, but unfortunately this
process is still in its origin.
Furthermore, people tend to believe computers more easily than other humans. This is especially true in fields of which they are afraid. One of those areas is people's health or more scientific medicine . Since it is not possible to manage the huge amounts of data without the help of computers, it is absolutely necessary to reduce the chances for mistakes as far as possible.
At least the industry has noticed those omissions and has started to spend bigger amounts of money in this area. This has not been done completely voluntarily. They have been forced to take this step by reasons like loss of image , higher expenditures for maintenance, disadvantages in the economic rivalry, negative publicity, contracts about error elimination, the change of liability laws for software towards the initiator principle, and the customer's increasing quality consciousness. The software developing industry has realized that the most efficient way to avoid those negative effects is to run a quality assuring program from the very beginning of the design phase of a computer program. Most companies have established their own testing and quality management departments, and have determined that those divisions should be strictly separated from the developing divisions.
This helps to reduce the costs , especially when producing new programs. But what should be done with software that has been written without a good quality assuring program. In general, it is not possible to make major changes in the design of such a product, but to increase its value, as many faults as possible have to be removed. However, those bugs have to be found first, and normally testing is one of the first things done in this location process.
Those considerations can be summarized in the following necessary steps: quality control during the whole process of software development, schoolings of the people who use the computers, and testing the software running on those systems. How can such a test be done?
Those considerations lead to the following structure of this thesis . For clarity reasons, and to make it easier to understand this paper, a definition of the most important terms out of the field of software testing will be given in the first part of chapter two. Problems, goals , and some strategies for testing will be explained. The focus will be on testing bigger programs.
Since the application DPV version 3.0 which will be tested in
chapter five is a medical database for monitoring the
course of diabetes mellitus illnesses, chapter
three will be an introduction about this disease. The application
itself will be described in chapter four.
This dBASE application has been written to collect data about young patients who suffer from diabetes mellitus . It has extensive statistic functions which above all are used to show the treating physician the quality and success of his medications . This part of the program makes it also possible to export anonymous data about the course of diabetes mellitus to ease research in this area. In chapter five this statistic part of the program DPV will be tested.
As all the modules which have been tested in chapter five have been rewritten in perl to make possible a more complete and saver test, some more detailed information about those programs, in addition to a crash-course in perl, will be given in chapter six.
Finally, the faults which have been found will be summarized in chapter seven. The dBASE source code will be checked for some of those bugs , and an attempt to find typical locations of those faults will be made.