Fundamentals of testing
- 1. BY : YUSRAN INFORMATION SYSTEM UIN SUSKA RIAU 2017 http://sif.uin-suska.ac.id http://fst.uin-suska.ac.id http://www.uin-suska.ac.id
- 2. In this section, we're going to kick off the book with a discussion on why testing matters. We'll describe and illustrate how software defects or bugs can cause problems for people, the environment or a company. As we go through this section, watch for the Syllabus termsbug, defect, error, failure, fault, mistake, quality, risk, software, testing and exhaustive testing.
- 3. Testing Principle - Testing is context dependent Testing is done differently in different contexts. For example, safety-critical software is tested differently from an e-commerce site.
- 4. Why is it that software systems sometimes don't work correctly? We know that people make mistakes - we are fallible. Do our mistakes matter? When do defects arise? What is the cost of defects?
- 5. We have seen that human errors can cause a defect or fault to be introduced at any stage within the software development life cycle and, depending upon the consequences of the mistake, the results can be trivial or catastrophic. Rigorous testing is necessary during development and maintenance to identify defects, in order to reduce failures in the operational environment and increase the quality of the operational system.
- 6. Testing helps us to measure the quality of software in terms of the number of defects found, the tests run, and the system covered by the tests. We can do this for both the functional attributes of the software (for example, printing a report correctly) and for the non-functional software requirements and characteristics (for example, printing a report quickly enough).
- 7. Testing Principle - Exhaustive testing is impossible Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Instead of exhaustive testing, we use risks and priorities to focus testing efforts.
- 8. As well as observing the driver actually driving, the examiner will ask questions or the driver will take a written exam to check their under standing of the rules of the road, road signs, and what to do in various traffic situations.
- 9. Test activities exist before and after test execution, and we explain those activities in this book. As a tester or test manager, you will be involved in planning and control of the testing, choosing test conditions, designing test cases based on those test conditions, executing them and checking results, evaluating whether enough testing has been done by Examining completion (or exit) criteria, reporting on the testing process and system under test, and presenting test completion (or summary) reports.
- 10. We can use both dynamic testing and static testing as a means for achieving similar test objectives. Both provide information to improve both the system to be tested, and the development and testing processes. Testing activities should start as early as possible in the software or system development life cycle and should be focused on defined objectives.
- 11. Reviewing defects and failures in order to improve processes allows us to improve our testing and our requirements, design and development processes. One phenomenon that many testers have observed is that defects tend to cluster. This can happen because an area of the code is particularly complex and tricky, or because changing software and other products tends to cause knock-on defects. Testers will often use this information when making their risk assessment for planning the tests, and will focus on known 'hot spots'.
- 12. If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new bugs. To overcome this 'pesticide paradox', the test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.
- 14. Testing can show that defects are present, but cannot prove that there are no 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.
- 15. There is another important principle we must consider; the customers for soft-ware - the people and organizations who buy and use it to aid in their day-to- day tasks - are not interested in defects or numbers of defects, except when they are directly affected by the instability of the software. The people using soft-ware are more interested in the software supporting them in completing tasks efficiently and effectively.