I think that one of the hardest things to do as a programmer is anticipate the ways in which your product will be used. If it’s not very powerful to start with, then it’s not likely that people will try to push the envelope of its capabilities. However, if it’s above a certain level, users will attempt things that the creator didn’t anticipate. Not knowing the details of the implementation, the users will expect to achieve a certain goal that exceeds capabilities.
I’m not very good at thinking outside the box in this way, and thus usually don’t come up with very creative test cases for my work. It’s unfortunate, but I think that it is (in some cases) a common problem of being too close to the code. I know what it’s supposed to do, I test to verify that it does that, but I have a hard time forcing myself to try to do something that wasn’t intended. I need to work on that.
However, in the case of D-RATS at least, I have a healthy contingent of people constantly working to break stuff. They don’t realize that they’re trying (well, some do), but without a manual, box, or guide telling them what is in and out of scope, they tend to push on it until it breaks. This has, undoubtedly, led to some of the better features and more robustness than I would have been able to accomplish alone.
A good example of this came about recently when one of my users told me that his map in D-RATS was getting slower and slower. I had just added a few significant performance enhancements to the map code, so I wasn’t sure if I had broken something in the process or what. After seeing one of his error messages, I asked him to send me his overlay files. The overlays are a function I added that allow users to put static points on the map of things that don’t move, which are overlaid with the actual radio stations that the map is intended to track. I have about ten such points on my map, and it’s quite useful. He sent me his overlays and I put them on my system and brought up the map to see if I could reproduce the performance issues he was experiencing. Here is what I saw:
Clearly, he had a different level of functionality in mind than I did. The phrase “pushing the envelope” applies quite well here. This, of course, led me to do quite a bit of work on the map code around the bits that draw the overlays. Hopefully this will improve things quite a bit.
Bravo, Dave. Bravo.