HW14: Testing Reflections

I found the author’s opening statement that testing accounts for half of the labor involved in building software to be quite surprising. It sounded just as obscure as Brooks’ rule of thumb that coding should only take 1/6 of a project’s time. Due to the coding habits I had developed in previous courses, I had always thought that writing code would make up a majority of the time spent on a software project.

I strongly agree with the author’s opening assertion that very few people actually enjoy testing. I haven’t met anyone yet who actually enjoys testing software, and reflecting back on my previous classes, I can definitely say that testing and debugging my projects was the most frustrating part of any assignment.

One part of the text that really stood out to me was then the author stated that “The statistics show that programming, done well, will still have one to three bugs per hundred statements.” That sounds like no matter how skilled a team or even an individual programmer is, and no matter how much testing is done, there will always be at least one bug that exists in a system.

I found the author’s list of the 5 phases of a tester’s mental life to be interesting. I used to consider testing and debugging to be different names for the same thing. However, the author’s perspective has illustrated that there is a difference between the two. Testing’s main goal is the prevention of bugs whereas debugging is the correction of bugs.

According to the text, debugging is the most expensive part of any software project. Testing software to show that there are bugs and debugging the software to fix the bugs is important in all systems, especially when lives are at stake, so it makes sense that testing and debugging accounts for half of the time spent on a project. The text book lists three stages for testing: development testing, release testing, and user testing. Development testing is testing that is performed by the members of a team working on a system. Release testing is a testing method to test a newer version of a software. User testing is when users are allowed to test a system in their own setting. All three of these methods are vital to software testing because software needs to be tested by different people with different perspectives. A software engineer might not think of the same techniques to break a system that a user might.

At the beginning of the semester, if I was asked how much time should be spent testing any given software, I probably would have responded around 10% or less. However, after all of the readings, both from the book and other sources, my perspective has changed vastly. Given the amount of time it is taking to test our semester project, I understand where the notion that half of the time for any project is spent on testing comes from. From the list of spacecraft accidents to the security of automobiles, the examples provided have illustrated the need for test driven development in any software endeavor, regardless of size or the impact it may have on the people who use it.