- Software Testing can not show the absence of errors
- There is no last bug in the software / application
- Maximum coverage through minimum test cases is a big challenge of testing.
- Even for simple program of loops, there can be over million paths – testable manually in million years. Domain of possible inputs is too large to test. Also, there are too many possible paths to test the program. Even if, theoretically speaking, one could design excellent test cases to detect all defects, does one have the luxury of time and resources to do so in practice?
- Preventive testing is very important. Verify documents, design, code at each stage of development to prevent errors from getting in. Use a variety of techniques for this. Code review itself throughs up many defects that may be too difficult to detect by execution of tests. On the other hand, test execution can detect errors that can not be easily detected by code reviews. Therefore, various techniques are complimentary in nature and it is only through their combined use that one can hope to detect most errors.
- Even though development tends to be given more importance than testing. A good test design is perhaps intellectually more challenging than the software design and development. Given reasonable practical limits to the quality of test design in practice, it is easy to understand that why it is difficult to uncover all defects through testing.
Source
Software Testing Myths & Facts
There are certain popular myths about the testing discipline which are deep rooted in the software development community. Over the years, with several major products shipped on time, with high quality helping keep the software maintenance costs within predicted and manageable numbers are helping shatter these myths.
Testing Myths & Facts
Herein we list some of those myths we’ve heard time and again and the facts associated with them that we really believe in:
Myth: Initiating testing activities earlier in the development cycle increases delivery time while reducing the number of features in the product.
Reality: Testing is not the time-consuming activity in a development lifecycle. Diagnosing and fixing defects are the time-consuming, bottleneck activities.
Myth: You can't test if you don't have a product to test.
Reality: Iterative testing isn't limited to testing code.
Myth: Continually regressing everything every time we change code is tedious and time consuming…but, in an ideal world, it should be done.
Reality: Regression testing doesn't mean "testing everything, every time."
Iterative regression testing means testing what makes sense in each phase and iteration. It also means modifying our coverage based on the impact of the change, the history of the product, and the previous test results.
Myth: It's not a bug -- the feature is working as designed.
Reality:The over-explanation of why the product is doing what it's doing is a common trap. Sometimes we just know too much. When defects are triaged and reviewed, we often explain away the reasons for the defect. Sometimes we tag defects as "works as designed" or "no plans to fix" because the application is actually working as it was designed, and it would be too costly or risky to make the design change. Similarly, we explain many usability concerns as "it's an external component" or "it's a bell and whistle." Our widgets or UI controls may have known limitations. Or we may even tell ourselves that "once the user learns to do it this way, they'll be fine."
Myth: A tester's only task is to find bugs.
Reality: This view of the tester's role is very limited and adds no value for the customer. Testers are experts with the system, application, or product under test. Unlike the developers, who are responsible for a specific function or component, the tester understands how the system works as a whole to accomplish customer goals. Testers understand the value added by the product, the impact of the environment on the product's efficiency, and the best ways to get the most out of the product.
Myth: We don't have enough resources or time to fully test the product.
Reality: You don't need to fully test the product -- you need to test the product sufficiently to reduce the risk that a customer will be negatively affected.
Myth: Testing should take place in a controlled environment.
Reality: The more the test environment resembles the final production environment, the more reliable the testing. If the customer's environment is very controlled, then you can do all your testing in a controlled environment. But if the final production environment is not controlled, then conducting 100 percent of your testing in a controlled environment will cause you to miss some important test cases.
source
