question archive 1) Exhaustive testing is not possible Yes! Exhaustive testing is not possible
1) Exhaustive testing is not possible Yes! Exhaustive testing is not possible
Subject:Computer SciencePrice:4.87 Bought7
1) Exhaustive testing is not possible
Yes! 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 exercise
In your opinion, Which operation is 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 activity and need to be tested thoroughly which brings us to our next principle Defect Clustering
2) Defect Clustering
Defect Clustering which states that a small number of modules contain most of the defects detected. This is the application of the Pareto Principle to software testing: approximately 80% of the problems are found in 20% of the modules.
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.
3) Pesticide Paradox
Repetitive use of the same pesticide mix to eradicate insects during farming will over time lead to the insects developing resistance to the pesticide Thereby ineffective of pesticides on insects. The same applies to software testing. If the same set of repetitive tests are conducted, the method will be useless for discovering new defects.
To overcome this, the test cases need to be regularly reviewed & revised, adding new & different test cases to help find more defects.
Testers cannot simply depend on existing test techniques. He must look out continually to improve the existing methods to make testing more effective. But even after all this sweat & hard work in 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
You think a company like MICROSOFT would not have tested their OS thoroughly & would risk their reputation just to see their OS crashing during its public launch!
4) Testing shows a presence of defects
Hence, testing principle states that - Testing talks about the presence of defects and don't talk about the absence 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
5) Absence of Error - fallacy
It is possible that software which is 99% bug-free is still unusable. This can be the case if the system is tested thoroughly for the wrong requirement. Software testing is not mere finding defects, but also to check that software addresses the business needs. The 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 user's needs & requirements.
To solve this problem, the next principle of testing states that Early Testing
6) Early Testing
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 in early stages. It is much cheaper to fix a Defect in the early stages of testing. But how early one should start testing? It is recommended that you start finding the bug the moment the requirements are defined. More on this principle in a later training tutorial.
7) Testing is context dependent
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. All the developed software's are not identical. You might use a different approach, methodologies, techniques, and types of testing depending upon the application type. For instance testing, any POS system at a retail store will be different than testing an ATM machine.
Purchase A New Answer
Custom new solution created by our subject matter experts
GET A QUOTE
Answer Preview
Answer:
Principles of Testing.
Exhaustive testing is not possible.
This is very true. Practically it is not possible to go through every line of code in a system under test. The goal is to design test cases that cover a wide range of system functions and scenarios. This is achieved by analyzing the riskiest functions that are prone to bugs and then prioritizing them accordingly. Proper planning and execution of the tests will lead to higher coverage which translates to higher confidence that the system works well.
Defect Clustering
This principle relies on the idea that certain modules have the most operational failures in a system as compared to others. Therefore, testing should be focused on those modules. 80 percent of defects are due to 20 percent of code this is the Pareto principle. This happens for most complex systems but still defect density can vary from one system to another. Some of the reasons for this variation are :
- How complex a component's functions are.
- How many 3rd party dependencies are there in the module.
- Legacy code in certain system modules.
- components under regular changes hence prone to bug accumulation.
Discovering one bug in one area of a module then there is a big possibility of uncovering more in the same module.
Pesticide paradox
The principle is derived from the idea of acquired immunity on crops when the same pesticide is used over and over again. The same case applies for software when the legacy testing methods, techniques, test cases, and scenarios are employed over a long period the system becomes immune to the tests and might mislead that the software is working well. To mitigate this it is advised to keep on changing the methods to discover new defects and bugs.
Testing shows the presence of defects
Testing is done so that to uncover problems before releasing the software for use in the Live environment. Testing is done to give is the confidence that the main functions are working well according to requirements and not to prove that the software is bug-free.
Comprehensive test strategy with all the suitable test cases, proper measure metrics of the modules tested and reports will help to show the effectiveness of the testing methods and yields desired confidence before deploying the software for use by the users.
Absence of Error fallacy
If a system does not meet the user needs and requirements then the system is a failure no matter the number of defects and bugs in the system. If a user can't navigate through the system then it a failure. Testing should be done in conjunction with the users to capture any usability issues and be sure that the software is doing what it was required initially. Fewer numbers of issues don't guarantee to ship software to the users. Meeting user requirements is as important as well too.
Early Testing
This is crucial as it enables defects to be located earlier on in the development life cycle. Bugs that are detected in the requirements stage are cheaper to amend as compared to bugs that are located later on in the development life cycle. In agile development, early testing is seen as a continuous process in the software life cycle, not a phase. This helps the development team to receive early feedback and be able to mitigate the various challenges that might exist.
Testing is context Dependent
Context is the basics of all types of testing done on any software or system. Different systems do different functions hence vary in the vulnerabilities that might exist in the system. An API based system is not the same as a system for Accounting or online purchases. Hence, what type of system is being tested will affect the approach that will be used to do that testing too.
