Tag: defect clustering

Test Case – a set of input values – steps to follow for pre-conditions- and post conditions for a particular test condition.

Major objective of testing- to prevent the defects (focus mostly on tester activity and ignore if generally mentioned as it may reflect to all the team members)

Example of failure – UI feature not working as expected from the customer point of view. (Need to see what are debugging steps and what ui issues)

Which of the following is defect and not a root cause – UI issue noticeable by the customer.

Risk Analysis- focus on areas where defects are noticed earlier – defect clustering

Pesticide paradox- repeating same test cases again and again- improvise to new test cases.

test Design – identifying the data to support test cases

Test implementation – prioritizing hte test procedures and create test data

Test Execution – Analyzing discrepancies to determine their cause

Test completion – Entering CR for open defect reports

Traceability-> test basis and test artifacts-? new test cases has increased the coverage of the requirements.

Tester mindset- ability to see what might go wrong

7 testing principles

1. Testing Shows presence of defects
2. Exhaustive testing is impossible
3. Early Testing
4. Defect Clustering
5. Pesticide paradox
6. Testing context dependent
7. Absence of error fallacy

1. Testing Shows the presence of defects – but not the absence- as we cannot make a statement at any point of time, we can say there are no more defects – difference constraints come in place.
2. Exhaustive testing is impossible – All permutation combinations of test cases are not possible as it may lead to infinite combinations. we do not have enough time or resources to complete all on time /schedule.
3. Early testing – Bring testers while Work products are being started like Business requirements and specs- if the defects found on those – it considered cheaper on the life cycle model – starting with draft reviews – it helps the project to be more successful
4. Defect clustering– in line with the defect density – defects in general cannot be assumed to be equally distributes as 2 defects for 10 modules each- could be 9 modules- may be shown more caution and less defect and 10th module not taken care much so may have one hundred defects. so all modules to be seen equally! more test cases added to mark on the defect density
5. Pesticide paradox – running same test case repeatedly is waste of time- so improvise the test cases often and if required add new test case or widen coverage based on the current understand- requirements may have changed slightly, technology may have changed. The current test cases may be outdated, to find defects.
6. Testing context dependent – online shopping cart vs safety critical system or an insurance app all 3 have different approaches or coverages /density – by which effort is proportional accordingly.
7. Absence of error is a fallacy – in general many test cases are run few defects found and got fixed, it’s not useful if the product is not useful for the end user- Requirements should be met by the developer so the product us ready for the launch! Test only stable softwares.