One of the first things that we learn as QA Analysts are the 7 principles of Testing, as set up by the ISTQB, which govern the overall tone and attitude of testers.These are open to interpretation, but you often come across them in various testing environments, and may find them useful in given circumstances.
Principle 1 – Testing shows presence of defects
If a defect exists within a piece of software, then testing can show the defect exists. But testing cannot prove that no defects are present in the piece of software. What testing can provide is decrease the probability of defects existing in the software. In simple terms; if the tests show up no defects, it doesn’t mean they are not present.
Principle 2 – Exhaustive testing is impossible
It is impossible for us to test everything. Often the total number of combinations permutation that allow for every combination of input would run into the millions, and would take 100s of years to complete. Most of us don’t live that long, and even the aliens among us have better things to do. The alternative to use instead of “Exhaustive testing” is something we call “Risk-Based Testing” which i will discuss in another post.
Principle 3 – Early Testing
The earlier on in the development lifecycle testing starts, the better. By testing early we can ensure the development requirements can actually be tested, and also influence the way the development proceeds.
Principle 4 – Defect Clustering
By being aware of defect clustering, we can ensure that testing is focused in those areas that contain the most defects.
Principle 5 – Pesticide paradox
If we ran the same tests over and over again, we would probably find the amount of new defects found would decrease. To avoid this, the tests should be regularly reviewed to ensure all expected areas of functionality are covered.
Principle 6 – Testing is context dependant
Depending on the item being developed, the way the testing is carried out will often differ. For example an ‘air traffic control system’ will undoubtedly be tested in a different way to a ‘children’s story book program’.
Principle 7 – Absence of errors fallacy
Just because you were able to submit a software that is seemingly free of defects, doesn’t necessarily mean that it is acceptable. If the system built is unusable and does not fulfil the user’s needs and expectations then finding and fixing defects does not help.