Xem mẫu

FOUNDATIONS OF SOFTWARE TESTING ISTQB CERTIFICATION Dorothy Graham Erik van Veenendaal Isabel Evans Rex Black CONTENTS Acknowledgements viii Preface ix 1 Fundamentals of testing 1 1.1 Why is testing necessary? 1 1.2 What is testing? 11 1.3 Testing principles 18 1.4 Fundamental test process 20 1.5 The psychology of testing 26 Chapter review 31 Sample exam questions 32 Exercise: Test psychology 33 Exercise solution 34 2 Testing throughout the software life cycle 35 2.1 Software development models 35 2.2 Test levels 41 2.3 Test types: the targets of testing 46 2.4 Maintenance testing 50 Chapter review 54 Sample exam questions 55 3 Static techniques 57 3.1 Reviews and the test process 57 3.2 Review process 59 3.3 Static analysis by tools 69 Chapter review 74 Sample exam questions 75 4 Test design techniques 77 4.1 Identifying test conditions and designing test cases 77 4.2 Categories of test design techniques 84 4.3 Specification-based or black-box techniques 87 4.4 Structure-based or white-box techniques 105 4.5 Experience-based techniques 112 4.6 Choosing a test technique 114 Chapter review 117 Sample exam questions 118 Exercises: Test design techniques 121 Exercise solutions 122 5 Test management 127 5.1 Test organization 127 5.2 Test plans, estimates, and strategies 132 5.3 Test progress monitoring and control 142 5.4 Configuration management 148 5.5 Risk and testing 149 5.6 Incident management 155 Chapter review 161 Sample exam questions 162 Exercise: Incident report 165 Exercise solution 166 6 Tool support for testing 169 6.1 Types of test tool 169 6.2 Effective use of tools: Potential benefits and risks 184 6.3 Introducing a tool into an organization 190 Chapter review 193 Sample exam questions 195 7 ISTQB Foundation Exam 197 Preparing for the exam 197 Taking the exam 199 Mock exam 201 Glossary 209 Answers to sample exam questions 227 References 231 Authors 237 Companies 239 Index 243 CHAPTER 1 Fundamentals of testing n this chapter, we will introduce you to the fundamentals of testing: why testing is needed; its limitations, 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 an understanding of the fundamentals of testing and be able to describe those fundamentals. 1.1 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 correspon ding terms `error` and `bug`. (Kl) 6 Explain the fundamental principles in testing. (K2) 1.1.1 Introduction 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. We`ll draw important dis-tinctions between defects, their root causes and their effects. We`ll explain why testing is necessary to find these defects, how testing promotes quality, and how testing fits into quality assurance. In this section, we will also introduce some fundamental principles of testing. As we go through this section, watch for the Syllabus terms bug, defect, error, failure, fault, mistake, quality, risk, software, testing and exhaustive testing. You`ll find these terms defined in the glossary. You may be asking `what is testing?` and we`ll look more closely at the defi-nition of testing in Section 1.2. For the moment, let`s adopt a simple everyday-life usage: `when we are testing something we are checking whether it is OK`. We`ll need to refine that when we define software testing later on. Let`s start by considering why testing is needed. Testing is necessary because we all make mis-takes. Some of those mistakes are unimportant, but some of them are expensive or dangerous. We need to check everything and anything we produce because things can always go wrong - humans make mistakes all the time - it is what we do best! Because we should assume our work contains mistakes, we all need to check our own work. However, some mistakes come from bad assumptions and blind spots, so we might make the same mistakes when we check our own work as we made when we did it. So we may not notice the flaws in what we have done. Ideally, we should get someone else to check our work - another person is more likely to spot the flaws. In this book, we`ll explore the implications of these two simple paragraphs again and again. Does it matter if there are mistakes in what we do? Does it matter if we don`t find some of those flaws? We know that in ordinary life, some of our mistakes do not matter, and some are very important. It is the same with software systems. We need to know whether a particular error is likely to cause problems. To help us think about this, we need to consider the context within which we use different software systems. 1.1.2 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 hap-pened 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. ... - tailieumienphi.vn
nguon tai.lieu . vn