Schaumburg, IL, USA (one of the many Chicago suburbs)
Post Thanks / Like
How many test cases for a search screen?
I to design a test plan for a search screen that is being reworked. There are 15 possible search criteria that can be searched upon. any combination is valid. The user can search with only one criteria or all 15 and any combination in between. what do you think the best aproach is for designing a test plan that covers as much of the search as possible. I seem to be flashing back to high school and remembering combinations and permutations from math class. but i'm not sure if that is the way to go. i've been told i have up to two weeks to write the plan and i should be thorough.
I'm sure you can handle the obvious stuff but don't forget:
1) Search for (both with something to find and nothing to find) EVERY character that can be obtained using a standard keyboard. Certain DB's don't like certain characters like ' for example. Do this for every criteria. I'd recommend automating this one.
2) Do the text input limits (i.e. you can enter 10 chars for 'title') match up with the lengths of the coresponding database fields or at least are they shorter. It's safer.
3) If a search is going to take a long time, make the software polite enough to inform the user. Give them the option to cancel if it's going to take a very long time.
4) populate the database with a zillion 'mr smiths' and search for them. See where it breaks. Put a limit on things before the stress point is reached.
5) Have a look at the DB after a search. check nothing extra has been created. I've had one before that DUPLICATED everthing it returned with some data missing.
6) Does it insist on some minimum criteria to be entered? It should - no-one want's to enter nothing, hit 'go' then watch helplessly while it returns all 500,000 records then crashes the system.
Hope this helps.
I know you really wanted the test cases for the regular stuff but I aint gonna do that for ya
P.S. A bit more of a specification might of helped. I guess you will realise this when you see how may of the above points don't really apply to your software!
[This message has been edited by Jules (edited 11-14-2001).]