1. Testing shows presence of defects
Testing contributes to find and fix defects BUT that's not the main objective. In the book they emphasize on the fact that testing can't prove if there are defects or none in the software/system.
2. Exhaustive testing is impossible
"Combinations of inputs and preconditions" are multiple.
Testing is therefore a set of activities planned and scheduled so time and cost are clearly defined. As it is not possible to test them "all", a test strategy is required for setting out test objectives and prioritizing test execution according to the risk analysis performed beforehand.
3. Early testing
Principle explained in previous posts.
4. Defect clustering
When a defect has been found in a functionality of the software, it becomes a potential cluster (a hotspot) with knock-on effects on related code areas.
That's why in the book they define this principle by saying: "a small number of modules contains most of the defects discovered during pre-release testing or show the most operational failures".
This should always be the focused area to take in account when planning future test activities.
5. Pesticide paradox
Tests have to evolve and make sure that they're still effective in finding undisclosed defects.
Pesticide paradox principle is related to defect clustering principle: over time, when a hostspot has been fixed, the dynamic or static acceptance tests too much repeated will no more reveal defects. These would therefore need continuous review so the focus can vary and be applied elsewhere.
6. Testing is context dependent
Criticality and way of testing are both related to software/system context.
In the book, they compared a military software versus an e-commerce website: it's obvious that they won't be similarly tested.
7. Absence-of-errors fallacy
Testing is performed to assess that the software/system fits its purpose and users expectations.
So finding no defects won't mean that it fulfills its initial requirements.
No comments:
Post a Comment