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
Pause the tutorial and think over the exercise
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 in fact 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 raised to 15
If you were to test all the possible combinations
Project execution time and costs will rise exponentially
Hence one of the testing principles states that exhaustive testing is not possible
instead we need the 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 operation is most likely to cause your operating system to fail
I'm
Sure most of you would have guessed opening 10 heavy graphics applications all at the same time
So if you were testing this operating system
You would realize that defects are likely to be found in a multitasking module and that needs to [be] tested thoroughly
Which brings us to [our] next principal defect?
clustering which states that a small number of modules contain most of the defects detected
With 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 another principle of testing called
Pesticide Paradox to overcome this the test cases need to be regularly reviewed and revised
Adding new and different test cases to help find more defects
But even after all this sweat and hard work and testing you can never claim your product is bug free to drive home this point
Let's see this video of the public launch of Windows 98
Let's plug it in its going to say hey
I see you put in a new device and it's going to load in the appropriate drivers you'll notice that this scanner build
whoa
moving right along
Must be why we're not shipping Windows 98
You would think a company like Microsoft would have tested their os
Thoroughly and would not risk their reputation just to see their os crashing during its public launch
Hence the testing principle states that testing shows the presence of 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 or a proof that no defects remain in the system
But what if you work extra hard taking all precautions and making sure your software product is
99% bug free and the software does not meet the needs and requirements of the client
Which leads us to [our] next principle which states that absence of error is a fallacy
finding and fixing defects does not help if the system build is unusable and does not fulfill the users needs and
requirements [to] fix this problem the next principle of testing
Early testing states that testing should start as early as possible in the software development [lifecycle]
So that any defects in the requirements or design phase are captured as well
we'll have more on this principle [in] a later 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 before we close this tutorial. Here's a quick recap of the seven testing principles