2.fundamental of testing
- 1. FUNDAMENTAL OF TESTING Disusun Oleh : Bobi Henfajri Setiawan Nim :11453104759 Program Studi (S1) :Sistem Informasi Testing Dan Implementasi Sistem Fakultas Sains dan Teknologi Universitas Islam Negeri Sultan Syarif Kasim Riau http://www.uin-suska.ac.id/http://sif.uin-suska.ac.id/ http://fst.uin-suska.ac.id/
- 2. In this chapter, we will introduce you to the fundamentals of testing: why testing is needed; its limitatio ns, objectives and purpose; the principles behind testing; the process that testers follow; and some of the psychological factors that testers must consider in their work. By reading this chapter you'll gain a n understanding of the fundamentals of testing and be able to describe those fundamentals.
- 3. Introduction In this section, we're going to kick off the book with a discussion on why testing matters. We'll de scribe and illustrate how software defects or bugs can cause problems for people, the environment or a company. We'll draw important distinctions between defects, their root causes and their effect s. We'll explain why testing is necessary to find these defects, how testing promotes quality, and h ow testing fits into quality assurance. In this section, we will also introduce some fundamental pri nciples of testing. As we go through this section, watch for the Syllabus terms bug, defect, error, failure, fault, mis take, quality, risk, software, testing and exhaustive testing. You'll find these terms defined in th e glossary.
- 4. Software systems context Some of the problems we encounter when using software are quite trivial, but others can be costly and damaging - with loss of money, time or business reputation - and even may result in injury or death. For example, suppose a user interface has typographical defects. Does this matter? It may b e trivial, but it could have a significant effect, depending on the website and the defect: -If my personal family-tree website has my maternal grandmother's maiden name spelt wrong, my mother gets annoyed and I have to put up with some family teasing, but I can fix it easily and only the family see it (probably). -If the company website has some spelling mistakes in the text, potential customers may be p ut off the company as it looks unprofessional. -If a software program miscalculates pesticide application quantities, the effect could be very significant: suppose a decimal point is wrongly placed so that the application rate is 10 times t oo large. The farmer or gardener uses more pesticide than needed, which raises his costs, has environmental impacts on wildlife and water supplies and has health and safety impact for the farmer, gardener, family and workforce, livestock and pets. There may also be consequent los s of trust in and business for the company and possible legal costs and fines for causing the en vironmental and health problems.
- 5. Causes of software defects Why is it that software systems sometimes don't work correctly? We know that people ma ke mistakes - we are fallible. If someone makes an error or mistake in using the software, this may lead directly to a pr oblem - the software is used incorrectly and so does not behave as we expected. However, people also design and build the software and they can make mistakes during the design a nd build. These mistakes mean that there are flaws in the software itself. These are called defects or sometimes bugs or faults. Remember, the software is not just the code; check t he definition of soft- ware again to remind yourself. When the software code has been built, it is executed and then any defects may cause the system to fail to do what it should do (or do something it shouldn't), causing a failure. No t all defects result in failures; some stay dormant in the code and we may never notice the m. When we think about what might go wrong we have to consider defects and failures arisi ng from: -errors in the specification, design and implementation of the software and system; -errors in use of the system; -environmental conditions; -intentional damage;
- 6. Role of testing in software development, maintenance and operations • 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 de velopment and maintenance to identify defects, in order to reduce failures in the operatio nal environment and increase the quality of the operational system. This includes looking for places in the user interface where a user might make a mistake in input of data or in t he interpretation of the output, and looking for potential weak points for intentional and malicious attack. • We may also be required to carry out software testing to meet contractual or legal require ments, or industry-specific standards. These standards may specify what type of techniqu es we must use, or the percentage of the software code that must be exercised.
- 7. The driving test – an analogy for s oftware testing of the driving to the point where the driver cannot pass. The format of the driving t est and the conduct of the examiner are worth considering: -The test is planned and prepared for. In advance of the test, the examiner has pl anned a series of routes which cover the key driving activities to allow a thorough assessment of the driver's performance. The drivers under test do not know what route they will be asked to take in advance, although they know the requirements of the test. -The test has known goals – assessing whether the driver is sufficiently safe to be allowed to drive by themselves without an instructor, without endanger ing themse lves or others. There are clear pass/fail criteria, based on the number and severity of faults, but the confidence of the examiner in the driving is also taken into accou nt. -As well as observing the driver actually driving, the examiner will ask questions o r the driver will take a written exam to check their under standing of the rules of th e road, road signs, and what to do in various traffic situations.
- 8. Defining software testing First, let's look at testing as a process: -Process – Testing is a process rather than a single activity – there are a series of activities involved. -All life cycle activities – Chapter 2 looks at testing as a process that takes place througho ut the software development life cycle. We saw earlier that the later in the life cycle we f ind bugs, the more expensive they are to fix. If we can find and fix requirements defects a t the requirements stage, that must make commercial sense. We'll build the right software, correctly and at a lower cost overall. So, the thought process of designing tests early in th e life cycle can help to prevent defects from being introduced into code. We sometimes re fer to this as 'verifying the test basis via the test design'. The test basis includes document s such as the requirements and design specifications. You'll see how to -Both static and dynamic – We'll see in Chapter 3 that as well as tests where the software code is executed to demonstrate the results of running tests (often called dynamic testing) we can also test and find defects without exe cuting code. This is called static testing. Thi s testing includes reviewing of documents (including source code) and static analysis. Thi s is a useful and cost effective way of testing.
- 9. The defect clusters change over time Testing Principle - Pesticide paradox If the same tests are repeated over and over again, eventually the same set of test cases wi ll no longer find any new bugs. To overcome this 'pesticide paradox', the test cases need t o be regularly reviewed and revised, and new and different tests need to be written to ex ercise different parts of the software or system to potentially find more defects. Over time, as we improve our whole software development life cycle and the early static t esting, we may well find that dynamic test levels find fewer defects. A typical test improv ement initiative will initially find more defects as the testing improves and then, as the def ect prevention kicks in, we see the defect numbers dropping, as shown in Figure 1.3. The first part of the improvement enables us to reduce failures in operation; later the improve- ments are making us more efficient and effective in producing the software with fewer def ects in it. As the 'hot spots' for bugs get cleaned up we need to move our focus else- where, to the n ext set of risks. Over time, our focus may change from finding coding bugs, to looking at the requirements and design documents for defects, and to looking for process improveme nts so that we prevent defects in the product
- 10. Debugging removes defects When a test finds a defect that must be fixed, a programmer must do some work to locate the defect in the code and make the fix. In this process, called debugging, a programmer will examine the code for the immediate cause of the problem, repair the code and check t hat the code now executes as expected. The fix is often then tested separately (e.g. by an i ndependent tester) to confirm the fix. Notice that testing and debugging are different activities. Developers may test their own fi xes, in which case the very tight cycle of identifying faults,debugging, and retesting is oft en loosely referred to as debugging. However, often following the debugging cycle the fix ed code is tested independently both to retest the fix itself and to apply regression testing t o the surrounding unchanged software.
- 11. Reference Graham, d., et al. 2006. Foundation of Software Tes ting: ISTQB certification London, UK: Internation al Thomson Business Press
- 12. Activity Diagram Kelola Data Haji
- 14. TERIMA KASIH