If you ask somebody the question ``What is the goal of a software test?'' you might get an answer like, ``The goal of a software test is to prove that a given computer program does what it is supposed to do''. This answer is wrong and demonstrates the necessity to define some fundamentals about software testing . A better response to this questions would be, ``The goal of a software test is to find faults made by the program during its execution''. But why is this definition so much better? The first reason is that it is, even for extremely simple programs, basically impossible to prove their correctness.
A small example to make this clearer [Beizer90]: The input of all programs is finite, and it can be interpreted as a bit-stream regardless of its meaning. If such an input stream is limited to 80 bits, and it is possible to process one input per microsecond, about twice the current estimated age of the universe is needed to check each possible input just once. And this does not solve the following problems : how do you generate these inputs, how do you verify them and last, but not least, how do you know that this program produces the same output each time you enter a specific input?
The second answer is also supported by the fact that it is definitely a fault if a program does something it is not supposed to do, but this is not covered by the first answer. For example should a program do calculations even if its input was invalid ?