While testing software, we do come across with cases where some kind of input is needed. Whether this is a manual input, e.g. user name for a login screen or a machine input, e.g. screen resolution or some kind of DB input, e.g. db triggers (do this if its a sunday, send SMS if there is a credit in a account), we need to worry about a large number of inputs. When we plan test cases for these scenarios, the nightmarish task is to identify a small set of these input values, since inputting each one of them is impractical and non-feasible solution.
For example, if we have to test Login Screen, I would probably start with normal alpha names, then probably alpha-numeric name and then the ones with special characters and so on. While for a Login screen, the problem is not very complex, it does tend to get complex if we have to identify inputs for a photo-share program, specifically a photo-uploader part. In this case probably it would be
1. low res files
2. high res files
3. files of a particular format
4. invalid files
and so on. The big question is that how do we decide on that golden set of inputs which we think would sort of solve our problem.
To solve this, what is typically done is ‘equivalence class’ method of creating buckets of ‘input classes’ and then only inputting few leading values from each bucket. So we would have following classes at a min for a simple login program viz.
1. Alpha 2. Numeric 3. Alphanumeric 4. Special chars 5. Invalid chars
and if we learn that this login is going to be used in non-english locales as well then probably
6. high ascill chars 7. localized chars and so on.
The basic assumption while creating an equivalence class is that the program will execute the same code for any value with in a class so if we check for one then probably we dont need to check for all. To have some additional coverage, folks typically club ‘Boundary Value’ method as well, which means that test the boundaries and a value which is beyond boundary and a value which is just before the boundary.
While this is all public knowledge, my suggestion to deal with a problem which needs a large no of input would be to do following.
FIVE Steps to test a program which needs a large no of input values
1. Think and decide what all possible values something can have.
2. Make two buckets. First bucket will have the ones which you think are more reasonable values, something which will happen 99 % of time. Take help from a workflow or a usablity expert or a customer rep to confirm your thinking. For example, a login name typically would not be more than 20 chars. So put all those things which has more than 20 chars in bucket no 2. This is the bucket which you are going to almost through later. The idea is to use our testing brain and spend time testing those things which you think a customer would try to do. So for a photo-uploader program, it wont be prudent to spend too much time on uploading same pic 20 times. Most likely a real customer would never do that, or a majority of customer would never do that.
This step is really important. If you dont know what values will an input-field take or do not understand that domain then look around for help, ask, inquire but just simply not cook values or assume things.
3. From the first bucket, create 5 sets which you assume make some kind of logical class. why I suggest five is that a simple solution is mostly an elegant and practical solution. There is no point in having many classes. If indeed your problem is as complex then divide the functionality are into two, say input-field-xyz (login-name-english, login-name-non’english) and input-field-abc.
4. Look into each of these classes and then see if there is a class which has a wider variety and probably benefit from a further division. But refrain from making too many.
5. From each set, choose 3 leading cases (most used, boundary values or just your pick) and test.
Thats about it. One additional tip is to always test using relevant values. So if you are picking a value from a alpha class for a login-name box then have a name like Bob or Richard or Asok, rather then having abc, xyx.
Questions, queries, or simply you want to share a point or two, then dont hesitate to put a comment or two.
happy testing !!