Homework #11 - 9/19 (Makeup)

Reading through these old assignments is a little bit depressing. Not in the sense that I don't like reading them, but just realizing how many of them I've actually already read, but never wrote a blog post on.

     Seeing as I have not written very many complicated programs, when I read that about half of the development time of a piece of software is devoted to testing and debugging, I was a little surprised. Can it really be so cumbersome? The author provided many references to back up his statement of this, and it was also mentioned in the Mythical Man Month article, in which the author stated that he devotes one third of the development schedule to designing, one sixth to implementing, then the rest (half) to testing and debugging - wow! I suppose it sounds intimidating, but I'm the inexperienced one here, so I'll take their word for it!
     One of the most interesting parts of this read for me, was the different phases of thinking about testing and debugging. The author has a funny line in the article: "I called the inability to distinguish between testing and debugging 'phase 0' because it denies that testing matters, which is why I denied it the grace of a number". Well said, sir. Well said. Phase 0 thinking assures that your software will have no testing, therefore no quality assurance, and therefore, no quality. Phase 1 thinking is assuming that when your tests succeed, the software works. But in reality, this is not the case. Myers says that it only takes one failed test to prove that software doesn't work, but even an infinite number of tests cannot prove that it does work. Phase 2 thinking is where you assume the software doesn't work. In this case, the tester is always trying to prove that the code is broken, and if perhaps it is not, testing will never end, because there are no bugs to reveal - but they keep trying. Phase 3 is thinking about testing and debugging as gaining confidence in the software. A successful test does not actually improve the quality of the software, but it increases our perception that it is quality software. Therefore, when we have gained an acceptable amount of confidence in the software through testing and debugging, is when we release it. And finally, phase 4 thinking is a state of mind of testing. Developers know there will be bugs, but the main goal is to write your code with testing in mind. The act of thinking about and designing tests while programming will increase your bug prevention, and make your code easier to test when the time comes. Although all of the testing strategies strive towards the same goal of quality software, this is the best. It not only reduces the amount of bugs by using preventative measures, but also makes the labor of testing easier because the code, itself, is more testable.