The first task in testing a multiplatform environment is to develop a list of potential concerns about that environment. The testing that follows will then determine the validity of those concerns. The recommended process for identifying concerns is error guessing.

Error guessing attempts to anticipate problems within the software package and its operation. The proverb “an ounce of prevention is worth a pound of cure” speaks to the error-guessing process. Studies by the IBM Corporation indicate that the same types of software defects occur with the same frequency from project to project. Just as medicine can predict that X percent of the 55-year-old age group will die of a heart attack during the year, so the software test experts can predict the types of defects that will occur in software.

This means that the types of problems that you encounter in one will occur in most other similar tests. The problem may surface in a slightly different way, but it will be the same basic problem. For example, the problem of data exceeding its allocated field size will appear sooner or later in almost all software applications. If you anticipate it and decide what you will do when it happens and how the software will react to the situation, successful use of the software will not be threatened.

Error guessing requires the following two prerequisites:

If the group that tested the software function is the same group doing the error guessing, they will know how the software works. Knowing the platforms may require the addition of platform-knowledgeable people to the error-guessing team.

Although it is possible to perform error guessing with one person, it is basically a brainstorming process. Thus, it is always better when two or more people participate. This is because of the powerful synergistic effect of a group. Synergism means that one individual’s comments spark another individual to think about something he or she might not have thought about without the other individual present.

Error guessing requires a recorder to write down the ideas developed by the group. Each member of the group is allowed time to express what he or she believes might go wrong with the software. Until every individual has had an initial opportunity to list problems, there can be no criticism or comment on what other individuals have stated. After the initial go-round, the recorder reads back these items one by one. At this point, open discussion—that is, interactive discussion—commences. One group rule of this discussion is that there can be no criticism of errors raised or the individual who raised them. All comments must be stated positively. If an individual believes that the type of error or condition raised is not realistic, the ensuing discussion should be based on the probability of occurrence rather than the point’s validity. If criticism is permitted during brainstorming, communication will cease and much of the value of the process will be lost.

The error-guessing process is normally very brief. In some instances, it lasts no longer than 15 minutes, and only rarely would it exceed 1 hour. However, the process does require total concentration. Therefore, the group should be removed from normal business interruptions during this exercise.

The end product of error guessing is a list of potential error conditions for additional investigation and testing. It is not up to the error-guessing team to determine what happens when these error conditions occur. They need to be familiar enough with the software to know whether there may be a problem, but they do not need to know all of the solutions. This will be done in future testing steps.

Error guessing is meant to be a relatively unstructured, unorganized process. Generally, sufficient ideas are generated to prepare a reasonably comprehensive list of potential problems—particularly when performed by two or more people. The following is a short list of questions to brainstorm during error guessing:

These questions are designed to spark ideas about what might go wrong within a platform. The questions are not intended to be complete, nor do they need to be answered precisely. Their sole purpose is to steer you into areas for further exploration regarding potential errors.

The concerns should be listed on Work Paper 19-1. Part 1 of the Work Paper provides space for listing multiplatform testing concerns, as well as any recommended test to address those concerns to determine whether they are valid or have already been handled by the software and/or platform.

The test must identify the platforms that must be tested. Ideally, this list of platforms and detailed description of the platforms would be input to the test process. If so, this step need only determine if those platforms are available in the test lab.

The needed platforms are either those that will be advertised as acceptable for using the software, or platforms within an organization on which the software will be executed. The platforms need to be described in detail. This information should be recorded on Part 2 of Work Paper 19-1. Note that the description of the Work Paper will list some of the items needed about each platform.

Testers must then determine whether those platforms are available for testing. If the exact platform is not available, the testers need to determine whether an existing platform is acceptable. For example, if an available platform did not contain some feature or configuration, would the existing platform provide a reasonable test? If so, that platform can be used for testing. If the needed platform is not available, the testers must make a determination of whether to obtain such a platform or accept the risk that the software will be released without testing that specific platform.

The determination of whether an available test platform meets the needed test platform should be recorded on Part 2 of Work Paper 19-1. If the platform is not available, testers should record the action they will take.

The testers need to determine whether the platforms available in the test room are acceptable for testing. This involves the following two steps:

Structural testing deals with the architecture of the system. Architecture describes how the system is put together. It is used in the same context that an architect designs a building. Some of the architectural problems that could affect computer processing include:

These are but a few of the potential architectural limitations placed on computer software. You must remember that each software system is finite and has built-in limitations. Sometimes the vendor tells you these limitations, sometimes you can find them if you search through the documentation, and sometimes you won’t know them until they occur. However, all limits can be determined through structural testing. The questions at hand are: Do you feel competent to do it? and Is it worth doing? The answers to these questions depend on the critical nature of the software and what would happen if your business was unable to continue computer processing because you reached the program limitation.

Structural testing also relates to file-handling problems. Such file problems include incorrect processing when the last record on file is updated or adding a record that will become the first record on a file. In the personal computer software market, literally thousands of people are writing software. Some have good ideas but are not experienced programmers; thus, they fall into the age-old traps of file manipulation problems.

As an aid in developing structural test conditions, the more common structural problem areas are listed in the following text. You can use this checklist either to determine which types of structural test conditions you want to prepare or to check the completeness of the structural conditions. Either way, it may spark you to add some additional test conditions to verify that the structure of your software performs correctly.

Have test conditions for each of the following transaction processing events been prepared:

Although some functional processing may be affected by various platforms, it is normally the structural component of the function that is affected. The test team needs to identify the structural components of functions that will be affected by the platform. They may want to use the error-guessing technique described in Task 1 to identify these structural components.

The potentially affected structural component should be documented on Work Paper 19-2. The Work Paper lists the structural component, then each platform that may affect that structural component, as well as how the structural component may be affected by the platform. The testers should then determine which tests are needed to validate that the structural component will or will not be affected by a platform.

Systems tend to fail at interface points—that is, the points at which control is passed from one processing component to another (for example, when data is retrieved from a database, output reports are printed or transmitted, or a person interrupts processing to make a correction). The purpose of this task is to identify those interfaces so that they can be tested. Note that some of these interfaces will also overlap the software structural components affected by the platform. If the test has been included in the structural component task Work Paper, it need not be duplicated in the test recommended in this task.

This is a two-part task. The first part is to identify the interfaces within the software systems. These interfaces should be readily identifiable in the software’s user manual. The second part is to determine whether those interfaces could be affected by the specific platform on which the software executes. This is a judgmental exercise. However, if there is a doubt in the tester’s mind, he or she should test that interface on all of the platforms that might affect that interface. The Work Paper should identify the platform on which the interface may be affected, the interface itself, the interface both to and from the potential effect of the platform, and the test(s) that should be undertaken to validate whether the interface is impacted by the platform. Note that this same test for a single interface may have to be performed on multiple platforms. Document the results of this task on Work Paper 19-3.

At the conclusion of this task, the tests that will be needed to validate multiplatform operations will have been determined. The remaining task will be to execute those tests.

The platform test should be executed in the same manner as other tests are executed in the seven-step software testing process described in Part Three of this book. The only difference may be that the same test would be performed on multiple platforms to determine that consistent processing occurs.