APPROACH:
As specified by equivalence class testing (ECT) procedures, a value taken from a class usually in the middle is a representative of that class. In other words one point within an equivalence class is just as good as any other point, that is as likely to expose any error as any member of the same class.
Regarding equivalence class testing, the following equivalence classes were considered:
As specified by equivalence class testing (ECT) procedures, a value taken from a class usually in the middle is a representative of that class. In other words one point within an equivalence class is just as good as any other point, that is as likely to expose any error as any member of the same class.
Regarding equivalence class testing, the following equivalence classes were considered:
VALID INPUTS:
variable steps
S1 = {steps | steps > 1}
variable locations-n
L1 = {location1 | location > 0}
L2 = {location2 | location 2 > location1}
.
.
.
L-n = {location-n | location-n > location-n-1
Invalid inputs were considered as anything not inside those equivalence classes, as well as specifically:
INVALID INPUTS:
variable steps
S1 = {steps | steps < 0 (a negative number)}
S1 = {steps | steps is a numerical integer}
variable locations-n
L-n = {location-n | location-n < 0 (a negative number)}
L-n = {location-n | location-n is a numerical integer}
However given the nature of the program we decided against testing using ECT, as the two variables are not wholly independent of each other. The number of locations is determined by the first input (steps) and thus is theoretically limitless - or at least only limited by the largest possible number stored in an integer variable. As well as that, the locations themselves are dependent on each preceding one wherein an input is only considered valid if it is greater than the previous one.
All of these conditions made testing using equivalence classes too cost-effective time-wise as it required us to consider the dependency of the various variables, reducing the benefits of ECT in that it is used for completeness and to avoid redundancy. We felt that it would be more prudent to use the time to test the program using Decision Tables which would largely cover the same aspects as the classes but with more consideration of the conditions themselves.
