This tutorial introduces the seven basic principles governing Software Testing.
- 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
- Trying to move the file when it is open
- You do not have the security rights to paste the file in Folder B
- Folder B is on a shared drive and storage capacity is full.
- Folder B already has a file with the same name, infact 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
- If you were to test the entire possible combinations project EXECUTION TIME & COSTS will rise exponentially.
- Hence, one of the testing principles states that EXHAUSTIVE testing is not possible. Instead, we need an optimal amount of testing based on the risk assessment of the application.
- And the million dollar question is, how do you determine this risk?
- To answer this let's do an exercise
- In your opinion, Which operations are most likely to cause your Operating system to fail?
- I am sure most of you would have guessed, Opening 10 different application all at the same time.
- So if you were testing this Operating system you would realize that defects are likely to be found in multi-tasking and needs to be tested thoroughly which brings us to our next principle Defect Clustering which states that a small number of modules contain most of the defects detected.
- By experience, you can identify such risky modules. But this approach has its own problems
- If the same tests are repeated over and over again, eventually the same test cases will no longer find new bugs
- This is the another principle of testing called "Pesticide Paradox"
- To overcome this, the test cases need to be regularly reviewed & revised, adding new & different test cases to help find more defects.
- But even after all this sweat & hard work in testing, you can never claim you product is bug-free. To drive home this point, let's see this video of public launch of Windows 98
- You think a company like MICROSOFT would not have tested their O.S thoroughly & would risk their reputation just to see their O.S crashing during its public launch!
- Hence, testing principle states that - Testing shows presence of defects i.e. Software 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 & make your software product 99% bug-free. And the software does not meet the needs & requirements of the clients.
- This leads us to our next principle, which states that-
- Absence of Error is a Fallacy i.e. Finding and fixing defects does not help if the system build is unusable and does not fulfill the users needs & requirements
- To fix this problem, the next principle of testing states that
- Early Testing - Testing should start as early as possible in the Software Development Life Cycle. So that any defects in the requirements or design phase are captured as well. More on this principle in a later training tutorial.
- And the last principle of testing states that the Testing is context dependent which basically means that the way you test an e-commerce site will be different from the way you test a commercial off the shelf application.
Summary of the Seven Testing Principles
Principle 1
|
Testing shows presence of defects
|
Principle 2
|
Exhaustive testing is impossible
|
Principle 3
|
Early Testing
|
Principle 4
|
Defect Clustering
|
Principle 5
|
Pesticide Paradox
|
Principle 6
|
Testing is context dependent
|
Principle 7
|
Absence of errors - fallacy
|