HW14: Testing Reflections

Testing is probably the most dreaded word to most developers. Even though the proper way to develop is by having clear test design, it still puts a drag on the developer. We must think of the problem were are trying to resolve by code but also think about how to reliably test it after we are finished. Most of my classes so far, I have used the code and debug way of coding. This has caused certain assignments to take much longer than they should have. I usually end stopping and rethinking how I am trying to solve the problem. Usually coming up with an idea on how to test the end product. I would save myself a lot of time if I wasn't so stubborn and went to the second route first. 

The different ways of thinking of testing bring to light some issues. For example, using testing to show the software works. As it is tested more the likeliness of it being reliable decreases because the likeliness of finding a bug increases. It's a conundrum for most people's minds because one would think that as you test all the possible cases, it would increase the confidence that the program is reliable.

Having a test that is unaware of the structure of the code is best because this person will not be biased. But if they do not have enough information about the objective of the code, they may make test that are superfluous. There is a balance between a tester having some knowledge and having too much bias. For certain small unit testing the programmer and tester are one in the same. The programmer must have freedom to code in the required functionality but they must also test as they go. This can lead to the programmer just coding and debugging.