One of the seven principles of testing is exhaustive testing is impossible. So how should we go about testing our applications? The answer is to use equivalence classes.
Say we have an input field that is designed to take the number of tickets you can book for a concert. One individual can buy up to 10 tickets. We want to test this. For example
We can divide up the range of possible values like this.
What emerges are four "classes" of tests that are created by the different ranges of valid and invalid possible inputs.
We only need one test in each class because, testing that 6 is OK would be equivalent to testing 7 is OK. They are both valid amounts, the result of the test would be the same or equivalent. There is no point in testing in this class more than once because the results are equal or equivalent. Same for the out of range values, we tested with 11, but would expect the same results for 50, 100, 1000 etc
We could also do some boundary value analysis by testing the boundaries of our values as defined in our equivalence classes. For example let us set a lower limit of -99, and an upper limit of 99. Then we might have a set of tests for the following values:
Can you see we test the values at each boundary? The min and max possible values as identified by our equivalence classes.
Use cases apply the same idea as equivalence classes, but scaled up and applied to a whole system. Below you can see a diagram of a system. Carefully selected user journeys are put together so that every part of the application is tested.
Can you see how each test lights up a different part of the application. One of those tests is a use-case, together they form a set of test cases. These test cases test the whole application (not exhaustively) section by section.
The output of the testing phase is fully tested software. Can you write end-to-end tests for your application, that demonstrate consideration for equivalence classes.