Chp1 How Failure Comes to Be
In general, a failure comes about in the four stages discussed in the following.
1.The programmer creates a defect
2.The defect causes an infection.
3.The infection propagates.
4.The infection causes a failure
Notevery defect results in an infection, and not every infection resultsin a failure. Hence, having no failures does not imply having nodefects. This is the curse of testing, as pointed out by Dijkstra. Testing can only show the presence of defects, but never their absence.
indeed, debugging is largely a search problem.
Chp 2 Tracking Problems
one of the key issues of software configuration management: to be able to recreate any given configuration any time
To separate fixes and features, use a version control system to keep fixes in branches and features in the main trunk.
Unless you have a problem-tracking system that neatly integrates withyour test suite, I recommend keeping test outcomes separate fromproblem reports.
problem-trackingsystems “should be usedexclusively as a place to store feedback whenyou cannot immediately modify the code.” Otherwise, you should create areproducible test case.
Six Stages of Debugging:
1. That can’t happen.
2. That doesn’t happen on my machine.
3. That shouldn’t happen.
4. Why does that happen?
5. Oh, I see.
6. How did that ever work?
In general, a failure comes about in the four stages discussed in the following.
1.The programmer creates a defect
2.The defect causes an infection.
3.The infection propagates.
4.The infection causes a failure
Notevery defect results in an infection, and not every infection resultsin a failure. Hence, having no failures does not imply having nodefects. This is the curse of testing, as pointed out by Dijkstra. Testing can only show the presence of defects, but never their absence.
indeed, debugging is largely a search problem.
Chp 2 Tracking Problems
one of the key issues of software configuration management: to be able to recreate any given configuration any time
To separate fixes and features, use a version control system to keep fixes in branches and features in the main trunk.
Unless you have a problem-tracking system that neatly integrates withyour test suite, I recommend keeping test outcomes separate fromproblem reports.
problem-trackingsystems “should be usedexclusively as a place to store feedback whenyou cannot immediately modify the code.” Otherwise, you should create areproducible test case.
Six Stages of Debugging:
1. That can’t happen.
2. That doesn’t happen on my machine.
3. That shouldn’t happen.
4. Why does that happen?
5. Oh, I see.
6. How did that ever work?