Testing shows presence of defects
Testing can show that defects are present, but cannot prove that there are no defects. Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found,it is not a proof of correctness.
2.Exhaustive testing is impossible
Testing everything (all combinations of inputs and preconditions) is not feasible except for trival cases. Instead of exhaustive testing, risk analysis and priorities should be used to focus testing efforts.
3. Early testing
To find defects early, testing activities shall be started as early as possible in the software or system development life cycle, and shall be focused on defined objectives.
4. Defect clustering
Testing effort shall be focused proportionally to the expected and later observed defect density of modules. A small number of modules usually contains most of the defects discovered during release testing, or is responsible for most of the operational failures.
5. Pesticide paradox
If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new defects. To overcome this “pesticide paradox”, test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to find potentially more defects.
6. Testing is context dependent
Testing is done differently in different contexts. For example, safety-critical software is tested differently from an e-commerce site.
7. Absence-of-errors fallacy
Finding and fixing defects does not help if the system built is unusable and does not fulfill the users’ needs and expectations
If you are facing any issue like can not see video so please login into Google with email what you forwarded to us Google Login or mail to administrator qatraining@infotek-solutions.com
June 17, 2015 at 5:59 am
Testing shows presence of defects
Testing can show that defects are present, but cannot prove that there are no defects. Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found,it is not a proof of correctness.
2.Exhaustive testing is impossible
Testing everything (all combinations of inputs and preconditions) is not feasible except for trival cases. Instead of exhaustive testing, risk analysis and priorities should be used to focus testing efforts.
3. Early testing
To find defects early, testing activities shall be started as early as possible in the software or system development life cycle, and shall be focused on defined objectives.
4. Defect clustering
Testing effort shall be focused proportionally to the expected and later observed defect density of modules. A small number of modules usually contains most of the defects discovered during release testing, or is responsible for most of the operational failures.
5. Pesticide paradox
If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new defects. To overcome this “pesticide paradox”, test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to find potentially more defects.
6. Testing is context dependent
Testing is done differently in different contexts. For example, safety-critical software is tested differently from an e-commerce site.
7. Absence-of-errors fallacy
Finding and fixing defects does not help if the system built is unusable and does not fulfill the users’ needs and expectations
Navigation
Loading Questions
If you are facing any issue like can not see video so please login into Google with email what you forwarded to us Google Login or mail to administrator qatraining@infotek-solutions.com
Edit Profile