My last post concerning DD Path Testing will include a few more test cases beyond the 16 I originally laid out in my previous posts. I will also detail a few flaws I discovered within the program and attempt to give possible solutions to these problems whilst explaining my further test cases.
The following test cases concerns what occurs when we input negative and decimal numbers. Obviously we can't allow a negative number of 'steps' or negative 'locations' as this doesn't makes sense for obvious reasons. Concerning decimal numbers, while we cannot have a fraction of a step , we can have decimal numbers as distances. However, in our assumptions relating to the schematics of the program given to us, we have decided that since the schematics define the gaps as being units, we are taking this to mean numbers of the natural set, i.e. positive, whole numbers.
Interestingly if we use a negative number as the number of 'steps', it does accept it. Clearly, this is a fault within the program. Besides this, it also only allows one 'location' to be entered although this has no bearing on the answer as it is 0 each time. This is most likely due to the logic of the program never allowing it to enter the third loop as the number of steps is already less than 0.
This is also another violation as it both accepts a negative number as a valid 'location' which it shouldn't and as a result, it remains a reason why the largest gap is 4 where it should technically be 1 in the first example and why it is 8 instead of 2. This kind of flaw would lead to incorrect results and may cause some consequences in the real world. As such, ensuring the program does not accept negative numbers at any stage in the program is integral.
This test case of decimal numbers covers both decimal or double numbers being entered in as both the number of 'steps' and the 'locations'. In both cases, the exception is caught and we are prompted to enter a valid input, even for negative decimal numbers.
The next two test cases I have conducted were simply random and I am still not entirely sure what the results relayed to me means. However, I do think both are a result of a logical or structural flaw in the program, something possibly overlooked. In any case, it is a good sign that we have stumbled upon something that is hard to understand how it occurred as that is confirmation we are testing correctly and thoroughly.
While at first, I was unsure how this answer was calculated, it does make sense when I looked over it again. First there is the issue of having all of the values on a single line. It seems to be causing trouble in this case, although it works for others. The largest gap it initially comes across is 11 which is also the correct answer. The program only requires one more valid input for its computation however due to the inputs being on a single line, it does not seem to process these as they contain a string. Although this seems to be untrue for the last line of input as it terminates the program. While it causes some confusion, it seems most of the issues would be resolved by entering each value and then entering a carriage return to make the process easier to read. However, there could be some changes made to the original program so it could process it either way the inputs are entered.
Although I am not totally sure what is happening in this test, I know that it is more than likely a programming error within the program code causing this unusual test result. Also it is possibly that all of the inputs on the same line is affecting the computer's ability to calculate here, as the above example. If I were to enter each input after a carriage return, this problem would cease. However, software testing is about breaking the program and finding faults in the code in order to create a better program.
With the last examples of my tests, I have come to the end of my testing process concerning DD Paths. While it took some time to understand the technique, I feel like I can test programs more confidently now and spot errors in code a little better. While this program we have is flawed, I believe that in keeping it fairly basic, we could understand all the different inputs we have to account for and why testing is important to make sure all of our statements of code are working correctly.
As I have pointed out in all of my test results, a rather substantial amount of changes to the program is necessary to handle all of the errors we have found. Of course, there may be other errors that DD Path Testing has missed and other testing techniques would find easier, however I feel like if most of the errors I pointed out in my posts were taken care of in the program, it would run the way it is supposed to. Until we find more errors with another batch of testing perhaps.
