A MODEL FOR TESTING

The Project : a real-world context characterized by the following model project.

Application : It is a real-time system that must provide timely responses to user requests for services. It is an online system connected to remote terminals.
Staff : The programming staff consists of twenty to thirty programmers.There staff is used for system’s design.


Schedule : The project will take 24 months from the start of design to formal acceptance by the customer. Acceptance will be followed by a 6-month cutover period. Computer resources for development and testing will be almost adequate.

Specification : means requirements.

Acceptance Test : The system will be accepted only after a formal acceptance test. The application is not new, so part of the formal test already exists. At first the customer will intend to design the acceptance test, but later it will become the software design team’s responsibility.


Personnel : Management’s attitude is positive and knowledgeable about the realities of such projects.

Standards : Programming and test standards exist and are usually followed. They understand the role of interfaces and the need for interface standards.

Objectives : The system is the first of many similar systems that will be implemented in the future. No two will be identical, but they will have 75% of the code in common. Once installed, the system is expected to operate profitably for more than 10 years.


Source : One-third of the code is new, one-third extracted from a previous, reliable, but poorly documented system, and one-third is being rehosted
History : One programmer will quit before his components are tested. Another programmer will be fired before testing begins. A facility and/or hardware delivery problem will delay testing for several weeks and force second- and third-shift work. Several important milestones will slip but the delivery date will
be met.


Overview
The process starts with a program embedded in an environment, such as a computer, an operating system, or a calling program. This understanding leads us to create three models:
a model of the environment,
a model of the program,
a model of the expected bugs.


From these models we create a set of tests, which are then executed. The result of each test is either expected or unexpected. If unexpected, it may lead us to revise the test, our model or concept of how the program behaves, our concept of what bugs are possible, or the program itself. Only rarely would we attempt to modify the environment.

The Environment

A program’s environment is the hardware and software required to make it run.
For online systems the environment may include communications lines, other systems, terminals, and operators. The environment also includes all programs that interact with—and are used to create— the program under test, such as operating system, loader, linkage editor, compiler, utility routines.


If testing reveals an unexpected result, we may have to change our beliefs (our model of the environment) to find out what went wrong. But sometimes the environment could be wrong: the bug
could be in the hardware or firmware after all