Testing Priciples & Vocabulary

The principles can be defined as
1. a rule or code of conduct;
2. a general or fundamental, law, doctrine or assumption;

In software domain, these principles focus lights to test engineers on software systems, how suppose to build them and how they expect to behave.

Principle #1
Testing is the process of exercising a software component using a selected set of test cases, with the intent of
(a) revealing defects,
(b) evaluating quality.

The term “defects” used in this and in subsequent principles represents any deviations in the software that have negative impact on its functionality, performance, reliability, security and or any other of its specified quality attributes.


Principle #2
When the test objective is to detect defects, then a good test case is one that has a high probability of revealing a yet undetected defect(s).

The test engineer expects to work as scientist does like he creates hypotheses to prove or disprove them; that is determine if the specific defect is present or absent. Base on hypotheses, tester must select specific inputs; determines correct outputs and then they will be executed. Test results are analyzed to prove / disprove the hypotheses.

Principle #3
The test results should be inspected meticulously.
Get more detail from article.

Principle #4
A test case must contain the expected output or result.
Expected outputs allow the tester to determine
(1) whether a defect has been revealed, and
(2) pass/fail status for the test. It is very important to have a correct statement of the output so that needless time is not spent due to misconceptions about the outcome of a test. The specification of test inputs and outputs should be part of test design activities.

Principle #5
Test cases should be developed for both valid and invalid input conditions.
This principle opens room for negative testing. Tester should create positive as well as negative test cases; he or she must not assume that the software under test will always be provided with valid inputs. Inputs may be incorrect for several reasons. The developer of the software component may be biased in the selection of test inputs and specify only valid inputs in the test cases to demonstrate that the software works correctly but good tester is one who is more apt to select invalid inputs as well.


Principle #6 The probability of the existence of additional defects in a software component is proportional to the number of defects already detected in that component.