Xpath and CSS Selector Cheat-sheet
We are offering various software testing research by learning to help you to achieve the best quality of your web, responsive and mobile applications. Check out the latest blogs & articles on various software testing blog topics like Manual Testing Concepts, New Tools, DevOps, Scrum, Test automation, security, mobile app, and many more.
Courses Available For Engineering Students:
General Principles of Testing:
===================
Testing can show that the product fails, i.e., that there are defects. Testing cannot prove that a program is defect-free. Adequate testing reduces the probability that hidden defects are present in the test object. Even if no failures are found during testing, this is no proof that there are no defects.
It’s impossible to run an exhaustive test that includes all possible values for all inputs and their combinations combined with all different preconditions. Software, in normal practice, would require an “astronomically” high number of test cases. Every test is just a sample. The test effort must therefore be controlled, taking into account risk and priorities.
Testing activities should start as early as possible in the software life cycle and focus on defined goals. This contributes to finding defects early.
Most defects are found in a few parts of the test object. Thus if many defects are detected in one place, there are normally more defects nearby. During testing, one must react flexibly to this principle.
Similarly, if the same tests are repeated over and over, they tend to lose their effectiveness: they don’t discover new defects. Old or new defects might be in program parts not executed by the test cases. To maintain the effectiveness of tests and to fight this “pesticide paradox,” new and modified test cases should be developed and added to the test. Parts of the software not yet tested, or previously unused input combinations will then become involved and more defects may be found.
Testing must be adapted to the risks inherent in the use and environment of the application. Therefore, no two systems should be tested in the exactly same way. The intensity of testing, test exit criteria, etc. should be decided upon individually for every software system, depending on its usage environment. For example, safety-critical systems require different tests than e-commerce applications.
Finding failures and repairing defects does not guarantee that the system meets user expectations and needs. Early involvement of the users in the development process and the use of prototypes are preventive measures intended to avoid this problem.