What
"Actual outcome or predicted outcome. This is the outcome of a test. See also, branch outcome, condition outcome or decision outcome."
BS 7925-1.British Computer Society Specialist Interest Group in Software Testing (BCS SIGIST)

Essentially the "outcome" is centred on behaviour:-

 *How we expect the software to behave (predicted outcome) for a given set of inputs and circumstances.
 *How software actually behaved (actual outcome)

Why?
The concept of "outcome" is a fundamental building block of testing. The variance between what we expect and what we actually experience is how we measure success.

Imagine that we have a component. It is decided that 10 tests will be enough to exercise all the paths in the code. Once all ten tests have been passed, (there is no variance between predicted and actual outcomes) we would know that the component will behave exactly as we expect.

The concept of outcome is scalable up to large volume soak testing. Millions of transactions can be passed through a corporate server farm. The predicted outcomes are that the firstly, transactions will be processed. Secondly that none of the servers will crash.

Who?
A number of potential roles can be expect to be involved in the outcome process.

 * The analyst who first writes the requirement upon which an outcome is based.
 * The test analyst or engineer deciding which tests to run. He will decide if each test has passed.
 * The Test technician who actually runs the tests and logs the results.

In the real world of course, we as testers take on many of the above roles. Usually at least he test engineer and and techniciant roles. On top of that is the test analyst role, so we become judge and jury over the test.

Where?
Anywhere testing takes place.

When?
The outcome is only really important before and after the test has ran. Respectively the outcome is either predicted or actual.

How?
Planning the test has to be the foremost part of the process. Whether we are testing with high ceremony a military communications system, or an ad hoc web page, we must plan. The basic fundamental artifact is the test specification. Here we need to show what the behaviour we expect to be exhibited by the software.

The underlying basis of "outcome" is of course the requirements. Ideally traceability should exist through from requirements gathering, build and integration. Thus when a test is complete, we can be sure that the component or system is behaving exactly as the customer expects.

Once the test has been ran, we need to record the behaviour of the software, given a set of inputs With the outcome recorded as actual, we can then compare it with our predicted outcome.

Both the outcome logging and the verification of the results can be automated or performed manually.