One of the test design process steps is to predict the probability of outcomes in each selected program path. Although the first thing you will want do is traverse these paths manually, that is a machine’s job, do not rush to tackle this problem. First, it can be a very difficult task. Secondly, you will try to replace yourself by a computer; however, none has succeeded in doing the job better than the computer. You have a higher probability of predicting the wrong results than the software engineer does of making mistakes with the program. Below are a few more attractive alternatives.

Existing tests. Nowadays, software developers spend about 80% of their time maintaining software products. Most testers and programmers modify already existing software. This means that 95 percent of your tests do not change from version to version. If you also closely control both the test development and software development processes, then you will have the oracle – a tool for determining whether the program passed your tests. If you want to focus on your core activities, outsource qa to Cherkassian professionals and they will keep your products shiny and healthy.

Old programs. Serious updates to programs do not always result in the corresponding changes in the test suite, so older programs can be used as an oracle. For example, the old program was written for MS DOS. Now you need to reinstall it on other platforms. Although such a reworking of the program can lead to its complete rewriting, the old program is an excellent oracle. Run your tests on it to get the expected results.

Previous versions. Even if the code that you are testing has been rewritten, as a rule, for most paths, correct results can be obtained from previous versions of the program. In the worst case, changes can be made to a small number of paths, but the difference in test results for the old and new versions of the program is easily predicted. Use the outcomes received for the previous version as the starting point for receiving outcomes for the corresponding paths in the new version.

Prototypes and model programs. You can build an overly elaborate prototype in order to get correct results.Good prototypes, as a rule, also have functionality. They cannot serve as a work program because they are either too slow or too large, or simply cannot work in a given operating environment.

If you do not have an elaborate prototype, you can get an oracle by building a model program. For example, if you have to write a program to fill out an income tax declaration, you would start by programming all forms in spreadsheets, and algebra and logic in some simple language, for example BASIC.