http://food.whistleblower.org/software_testing_ron_patton.pdf
Chapter 1 Software Testing Background
1. In the Year 2000 bug example, did Dave do anything wrong?
- Not if the product spec and design goals for the software never stated that the product should work beyond year 2000.
- A software tester should have tested for and found the bug. The team could then decide whether to fix it.
2. True or False: It’s important what term your company or team calls a problem in its software.
False. It’s not important, but the term used often reflects the personality of the team and how they approach the finding, reporting, and fixing of the problems.
3. What’s wrong with just testing that a program works as expected?
- At most, that’s only half the testing problem. Users don’t always follow the rules, and testers need to prove out what happens when they don’t. Also, if testers don’t approach their testing with a gotta-break-it attitude, they will miss bugs.
4. How much more does it cost to fix a bug found after the product is released than it does from the very start of the project?
From 10 to 100 times or even higher!
5. What’s the goal of a software tester?
The goal of a software tester is to find bugs, find them as early as possible, and make sure they get fixed.
6. True or False: A good tester relentlessly strives for perfection.
False. A good tester knows when perfection isn’t attainable（可達到的） and when “good enough” is reached.
7. Give several reasons why the product specification is usually the largest source of bugs in a software product.
- Often a spec isn’t even written—remember, if you can’t say it, you can’t do it. - Other reasons are that the spec exists but it isn’t thorough, it’s constantly changing, or it’s not communicated to the rest of the development team.
Chapter 2 The Software Development Process
1. Name several tasks that should be performed before a programmer starts writing the first line of code.
- The development team needs to understand the customer requirements and define the features in a product spec.
- A detailed schedule should be created so team members know what work has been completed and what work remains to be done.
- The software should be architected and designed, and the test team should start planning their work.
2. What disadvantage is there to having a formal, locked-down specification?
If the market changes because of the release of a competitor’s product or changing customer needs, there’s no flexibility to adjust the software.
3. What is the best feature of the big-bang model of software development?
It’s simple. Period.
4. When using the code-and-fix model, how do you know when the software is ready to release?
There’s no real exit criteria for the code-and-fix process except for when someone, or the schedule, says that it’s time to stop.
5. Why can the waterfall method be difficult to use?
Just like with salmon, it’s difficult to swim upstream. Each step is a discrete, standalone process that follows the one before it. If you get to the end and find that something should have happened further up, it’s too late to go back.
6. Why would a software tester like the spiral model best?
They’re involved very early in the development process and have the opportunity to find problems early, saving the project time and money.
Chapter 3 The Realities of Software Testing
1. Given that it’s impossible to test a program completely, what information do you think should be considered when deciding whether it’s time to stop testing?
There is no correct answer for when to stop testing. Each project is different.
Examples of the information that might go into the decision would be:
Are lots of bugs still being found?
Is the team satisfied with the number and types of tests that have been run?
Have the reported bugs been evaluated to decide which ones to fix and which ones not to fix?
Has the product been validated against the user’s requirements?
2. Start the Windows Calculator. Type 5,000-5= (the comma is important). Look at the result. Is this a bug? Why or why not?
The answer you get is 0, not 4095 as you would expect. The reason is that the , (comma)was automatically converted to a . (decimal point). What you calculated was 5.000-5=0,not 5,000-5=4995. To determine if this is a bug, verify this operation against the product specification. It might state that commas are to be converted to decimal points. You should also validate this “feature” against the user requirements. Find out if most users want this to occur or if it would be confusing.
您得到的答案是0，而不是您期望的4095。 原因是，（逗號）已自動轉換爲。 （小數點）。 您計算的是5.000-5 = 0，而不是5,000-5 = 4995。 要確定這是否是錯誤，請對照產品規格驗證此操作。 它可能會指出逗號將轉換爲小數點。 您還應該根據用戶要求驗證此“功能”。 找出大多數用戶是否希望這種情況發生，或者是否會造成混淆。
3. If you were testing a simulation game such as a flight simulator or a city simulator, what do you think would be more important to test—its accuracy or its precision?
The purpose of a simulation game is to put the player into an artificial environment that mimics a real-world scenario. Flying a flight simulator should look and feel like flying a real plane. Running a city simulator should reflect what happens in a real city. What’s most important is how accurately the simulator reflects reality. Does the plane fly like a Boeing 757 or Piper Cub? Does the skyline of the city look like the city it represents?
After the software has accuracy, precision can follow. If you think about the advancement of simulation games over the years, this is exactly what has happened.
4. Is it possible to have a high-quality and low-reliability product? What might an example be?
- Yes, but it depends on the customer’s expectations for quality.
- Many people buy high-performance sports cars that are considered to be high quality for their acceleration and speed, their style, and their fit and finish. Often these same cars are notoriously unreliable, frequently breaking down and being expensive to repair. Their owners don’t consider this poor reliability to be an aspect of quality.
5. Why is it impossible to test a program completely?
- With any software other than the smallest and simplest program, there are too many inputs, too many outputs, and too many path combinations to fully test.
- Also, software specs can be subjective and be interpreted in different ways.
6. If you were testing a feature of your software on Monday and finding a new bug every hour, at what rate would you expect to find bugs on Tuesday?
- Two axioms come into play here.
- The first—that the number of bugs remaining is proportional to the number of bugs you’ve already found—means that you won’t come in on Tuesday and miraculously find the software to be perfect.
- The pesticide paradox tells you that if you continue to run the same tests over and over that you eventually won’t find new and different bugs until you add more tests.
- Given these two axioms, you will probably continue to find bugs at the same rate or slightly less.
您可能會繼續以相同的速率或略低的速度發現錯誤。