Fundamentals of testing
- 1. FUNDAMENTALS OF TESTING Nama: Suci Ayu Mawarni Nim: 11453201908 Sistem Informasi Sains dan Teknologi Universitas Islam Negri Sultan Syarif Kasim Riau
- 2. WHY IS TESTING NECESSARY? 1) Describe, with examples, the way in which a defect in software can cause harm to a person, to the environment or to a company. (K2) 2) Distinguish between the root cause of a defect and its effects. (K2) 3) Give reasons why testing is necessary by giving examples. (K2) 4) Describe why testing is part of quality assurance and give examples of how testing contributes to higher quality. (K2) 5) Recall the terms 'mistake', 'defect', 'fault', 'failure' and the corresponding terms 'error' and 'bug'. (K1) 6) Explain the fundamental principles in testing. (K2)
- 3. Software systems context 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. These days, almost everyone is aware of software systems. We encounter them in our homes, at work, while shopping, and because of mass-communication systems. More and more, they are part of our lives. We use software in day-to-day business applications such as banking and in consumer products such as cars and washing machines. However, most people have had an experience with software that did not work as expected: an error on a bill, a delay when waiting for a credit card to process and a website that did not load correctly are common examples of problems that may happen because of software problems. Not all software systems carry the same level of risk and not all problems have the same impact when they occur. A risk is something that has not happened yet and it may never happen; it is a potential problem. We are concerned about these potential problems because, if one of them did happen, we'd feel a negative impact. When we discuss risks, we need to consider how likely it is that the problem would occur and the impact if it happens. For example, whenever we cross the road, there is some risk that we'll be injured by a car. The likeli- hood depends on factors such as how much traffic is on the road, whether there is a safe crossing place, how well we can see, and how fast we can cross. The impact depends on how fast the car is going, whether we are wearing protective gear, our age and our health. The risk for a particular person can be worked out and therefore the best road-crossing strategy.
- 4. When do defects arise? In Figure 1.1 we can see how defects may arise in four requirements for a product. We can see that requirement 1 is implemented correctly - we understood the customer's requirement, designed correctly to meet that requirement, built cor- rectly to meet the design, and so deliver that requirement with the right attributes: functionally, it does what it is supposed to do and it also has the right non-functional attributes, so it is fast enough, easy to understand and so on. With the other requirements, errors have been made at different stages. Requirement 2 is fine until the software is coded, when we make some mistakes and introduce defects. Probably, these are easily spotted and corrected during testing, because we can see the product does not meet its design specification. The defects introduced in requirement 3 are harder to deal with; we built exactly what we were told to but unfortunately the designer made some mis- takes so there are defects in the design. Unless we check against the require- ments definition, we will not spot those defects during testing. When we do notice them they will be hard to fix because design changes will be required.
- 5. WHAT IS TESTING? Syllabus learning objectives. What is testing? 1 Recall the common objectives of testing. (K1) 2 Describe the purpose of testing in software development, maintenance and operations as a means to find defects, provide confidence and infor mation, and prevent defects. (K2) Defining software testing With that analogy in mind, let's look at the ISTQB definition of software testing. Let's break the definition down into parts; the definition has some key phrases to remember. The definition starts with a description of testing as a process and then lists some objectives of the test process. 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 throughout the software development life cycle. We saw earlier that the later in the life cycle we find bugs, the more expensive they are to fix. If we can find and fix requirements defects at 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 the life cycle can help to prevent defects from being introduced into code. We sometimes refer to this as 'verifying the test basis via the test design'. The test basis includes documents such as the requirements and design specifications. You'll see how to do this in Chapter 4.
- 6. • 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. This testing includes reviewing of documents (including source code) and static analysis. This is a useful and cost effective way of testing. • Planning – Activities take place before and after test execution. We need to manage the testing; for example, we plan what we want to do; we control the test activities; we report on testing progress and the status of the software under test; and we finalize or close testing when a phase completes. Chapter 5 covers these test management activities. • Preparation – We need to choose what testing we'll do, by selecting test con ditions and designing test cases. Chapter 4 covers the test design activities. • Evaluation – As well as executing the tests, we must check the results and evaluate the software under test and the completion criteria, which help us decide whether we have finished testing and whether the software product has passed the tests. • Software products and related work products – We don't just test code. We test the requirements and design specifications, and we test related documents such as operation, user and training material. Static and dynamic testing are both needed to cover the range of products we need to test.
- 7. TESTING PRINCIPLES 1 Explain the fundamental principles in testing. (K2). TABLE Testing principles:
- 8. FUNDAMENTAL TEST PROCESS 1 Recall the fundamental test activities from planning to test closure activities and the main tasks of each test activity. (K1) Introduction As we have seen, although executing tests is important, we also need a plan of action and a report on the outcome of testing. Project and test plans should include time to be spent on planning the tests, designing test cases, preparing for execution and evaluating status. The idea of a fundamental test process for all levels of test has developed over the years. Whatever the level of testing, we see the same type of main activities happening, although there may be a different amount of formality at the different levels, for example, component tests might be carried out less formally than system tests in most organizations with a less documented test process. The decision about the level of formality of the processes will depend on the system and software context and the level of risk associated with the software. So we can divide the activities within the fundamental test process into the following basic steps: – planning and control; – analysis and design; – implementation and execution; – evaluating exit criteria and reporting; – test closure activities.
- 9. THE PSYCHOLOGY OF TESTING Independent testing – who is a tester? The mindset we want to use while testing and reviewing is different from the one we use while analyzing or developing. By this we mean that, if we are building something we are working positively to solve problems in the design and to realize a product that meets some need. However, when we test or review a product, we are looking for defects in the product and thus are critical of it. Suppose you were going to cook a meal to enter in a competition for chefs. You select the menu, collect the ingredients, cook the food, set the table, and serve the meal. If you want to win, you do each task as well as you can. Suppose instead you are one of the judges evaluating the competition meals. You examine everything critically, including the menu, the ingredients, the methods used, keeping to time and budget allowances, choice of ingredients, the elegance of the table setting and the serving, and the look and taste of the meal. To differentiate between the competition chefs, you'll praise every good aspect of their performances but you'll also note every fault and error each chef made. So it is with software testing: building the software requires a different mindset from testing the software.