Scribd
Upload
156 views21 pages

General Testing Principles

Testing shows presence of defects Exhaustive testing is impossible Early testing Defect clustering Pesticide paradox Testing is context dependent Absence-of-errors fallacy

Uploaded by

Dhirajlal Chawada
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
156 views21 pages

General Testing Principles

Testing shows presence of defects Exhaustive testing is impossible Early testing Defect clustering Pesticide paradox Testing is context dependent Absence-of-errors fallacy

Uploaded by

Dhirajlal Chawada
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 21

General Testing Principles

General Testing Principles


Testing shows presence of defects Exhaustive testing is impossible Early testing Defect clustering Pesticide paradox Testing is context dependent Absence-of-errors fallacy

Consider a scenario where you are moving a file from Folder A to Folder B

think of all the possible ways you can test this apart from the usual scenarios you can also test the following conditions

Scenario
Trying to move the file when it is open. You do not have security rights to paste the file in Folder B. Folder B is on Shared drive and storage capacity is full. Folder B already has a file with the same name.

the list is endless.........

Or Suppose you have 15 input fields to test each having 5 possible values

the number of combinations to be tested would be 5^15 = 30517578125!!

If you were to test all the possible combinations project EXECUTION TIME & COSTS will rise exponentially
Hence one of the testing principle states that EXHAUSTIVE testing is not possible. Instead we need optimal amount of testing based on the risk assessment of the applications.

Exhaustive testing is impossible


Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases.

Instead of exhaustive testing, we use risks and priorities to focus testing efforts.

TriviaWhich operation is most likely to cause your Operating system to fail? A) Opening Microsoft Word B) Opening Internet Explorer C) Opening 10 different application all at the same time.

TriviaAnswer : C) Opening 10 different application all at the same time.

So if you would be testing this Operating System you would realize that defects are likely to be found in multi-tasking module and needs to be tested thoroughly

Defect clustering
In most cases, it can be seen that the majority of the detected defects are caused by a small number of modules, i.e. the distribution of defects are not across the application but rather condensed in particular areas of the application. This is particularly true for enterprise systems where the complexity, size, continuous change and developer inexperience can impact the quality of the system and affect particular modules. This analogy is based on the Pareto principle, also known as the 80-20 rule, where it is stated that approximately 80 per cent of the problems are caused by 20 per cent of the modules. This can give a good indication that when a defect is found in one area of the application, chances are there are more defects in that particular area, so it is worth investing more time to test that particular area of the application to find as many defects as possible. However, this should not deter testers to ignore the rest of application as there may be other defects scattered around.

Defect clustering
A small number of modules contain most of the defects discovered during pre-release testing or show the most operational failures.

By experience you can identify such risky modules

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 bugs.

This is the another principle of testing called "Pesticide Paradox"

Pesticide paradox
Insects that survive the use of pesticide are those that are more immune to the poison than others. These bugs' offspring are then also likely to be immune to the pesticide. This requires that pesticide companies continually work at developing new poisons that will kill whatever survived their previous products. The same occurs in software. If we create bug prevention or testing processes that tend to prevent and find particular types of bugs, other types of bugs will thrive because our attention is focused elsewhere. Also, designers, developers , and testers are likely to learn from their mistakes and not make the same mistakes again -- they will make new ones. This causes scripted testing -- whether manual or automated -- to become less effective over time.

To overcome this 'pesticide paradox', the 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 potentially find more defects

You cannot claim that your software is BUG-FREE

To Drive on this point lets see an example of public launch of Windows 98


At a Spring Comdex demo of Windows 98 on Monday in Chicago, Bill Gates got to see what's it actually like to use NT's little brother. The OS crashed while the world's richest man was demonstrating it to a packed house, sending its dire death message onto huge monitors for all to see. As Microsoft product manager Chris Capossela quickly moved to remove the offensive message from the screens, Gates quipped "That must be why we're not shipping Windows 98 yet."

Do you think Microsoft would not have tested their OS thoroughly and would risk their reputation just to see their OS crashing during its public launch

Testing shows presence of Defects


Hence the next principles states that - Testing shows presence of defects i.e. 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.

But what if you work extra hard taking all precautions and make your Software product 99% Bug FREE
Software does not meet the needs and requirements of the clients

Absence of errors fallacy


Finding and fixing defects does not help if the system built is unusable and does not fulfill the user's needs and expectations.

Early testing
Testing activities should start as early as possible in the Software Development Life Cycle So that any defects and requirements on design phase are captured as well

Testing is context dependent


which basically means testing is done differently in different contexts i.e. the way you test the e-commerce site will be different from the way you test the commercial application

Thank You!

You might also like