Software Testing - HW10

HW10
8.7 Write a scenario that could be used to help design tests for the wilderness weather station system.
A possible scenario would be a day during which there were three distinct weather types. In the morning it was cool, then it rained, then it was warm and humid. A technician could analyze the data provided by the weather station and examine it for accuracy and proper transitions. For example, was the rain reported within the proper time, and was the temperature/humidity change in the afternoon reported accurately.

8.10 A common approach to system testing is to test the system until the testing budget is exhausted and then deliver the system to customers. Discuss the ethics of this approach for systems that are delivered to external customers. 
Outside of ethics, this just isn't a good testing approach. It is lazy and will not create good testing practices. Ethically, if a system is being delivered to external customers they have a right to fully tested software. Tests should be exhaustive and they shouldn't stop when the testing budget runs out. What if there was a whole section of the system that hadn't been tested due to the fact that the testing budget was stingy, or the quality assurance team was underfunded? Then the customers are being presented with a poor quality and not fully tested product. This will only end up reflecting back on the company and paint them in a poor light. Therefore, this is not only an ethically unsound practice, but is bad publicity for the company delivering the system.

Reading Response
I feel that there is not enough of an emphasis on testing and quality assurance. As the author states, there is a myth that if we were better at coding, there wouldn't be bugs. Certainly we could work towards preventing bugs but they will happen regardless of our efforts, and it's part of being a good coder to test for those bugs. One of the problems is that it's easy to ignore testing in favor of band-aid fixes. It's admittedly much more difficult to create a testing plan, and write code that will help you test accurately and completely later on. It's simple to "cowboy code" or just write code, if it doesn't work slap on a quick fix, and keep going. One has to make the conscious choice to follow good coding practice. And certainly, one has to keep in mind the different testing phases and be aware of their thoughts in regards to testing. The 5 phases outlined in this article, I feel, are an excellent summarization of the "attitudinal progression" that one goes through.

The majority of the article seems to be focused on separating concepts that are often tangled together, or mistaken as one idea. I especially like the distinction between testing and bugging. As stated in the text, testing is used in order to identify bugs. Testing begins with known conditions and has a predictable outcome. Bugging is not necessarily defined and the outcome is not always predictable. Essentially, testing is more structured, organized and can be planned out. However, debugging requires in-depth knowledge of the code, as one must know what's going wrong and how to fix it.