Question about Database Data

[rcallicotte]

This is to all professional programmers, either who are or who have programmed using a database back-end over the Internet.

Is it proper to acknowledge that testing of a web program that connects to data can be tested without the proper amount of data?  Can a miniaturized test set really do the trick?

The facts - The online exam must have 100 questions with the question / answer test set grabbing 60 of these questions taken from a pool of all of a student's core courses and 40 of these questions from a pool of the student's electives.  I have not been given even 10% of the actual data for this and have been asked to test with that.  I added some fake data of my own, but it's only a small representative of what I need to include the wide spread of courses I need.  Would anyone think this is enough and, if so, how so?

I simply think that the minimal data set of less than 10% of the actual data would prevent thorough testing.  I have tested functionality, but think the missing data could prevent finding bugs not otherwise accessible.  If you agree, please let me know.

[FrankB]

depends on what it is that you would like to test.
Do you wish to test performance, concurrent transactions? Do you wish to check the algorithm that randomly picks questions from a pool? Or maybe some thing else?

If it's whether the algorithm works as expected, like, evenly pick question from the pool, then maybe you would want more data. If it's just a couple hundred data elements I need, I usually just use excel (or rather openoffice calc) to generate a couple hundred rows, which I save as a csv and then insert in to a test db. I mean, you wouldn't need full blown questions and answers for some of these test. You could just use "Q 1" to Q 1000" and "A 1" to "A 1000".

That's not a real testing methodology, I realize that, but worked for me in private.

Cheers,
Frank

[rcallicotte]

Thanks Frank.  That's what I've done, basically.  The problem in this case is that I need 70 times 40 rows of data with each row having some stringent requirements due to key constraints.  I don't have time to figure out something at that level without just producing the data, which was to be given to me about a year ago.  LOL  Anyway, the testing is basically for functionality to see if it works with various students' IDs and to see if the randomization works without grabbing the wrong courses in the selection set.  This sort of testing would introduce enough necessary pattern randomization to test the basics of the exam.  It's a timed exam and has to not lose the question / answer sets in the process.  With minimal testing, everything has been fine. 

We will do a Beta test with actual students before release, so it should eventually be okay. 

[otakar]

A couple of points of advice I can offer. One, make sure that the testing is not only performed by the programmer. End user testing is very beneficial and maybe even crucial. Glad that beta testing is part of the picture. Make sure you build in enough time to implement any necessary fixes and do a retest (cycle). Two, the volume of the test data may not be as important as its variety, i.e. covering all the possibilities. In your specific case, this would be having very short questions as part of the pool and then very long ones (up to the limit). If there are any IDs involved, assuming these are numeric, make sure you have the lowest number in the pool and the highest (if there is a maximum). Make sure you include special characters in your fields if they are allowed. Make sure to include very long words (to test display and line wrapping). To test any algorithms regarding selection and randomizing, I would think you could come up with a programmatic way of generating test data and perform a limited (unit) test. And finally, it will probably depend on how this application is used and if it is a high impact critical app. If it is, a robust testing phase is obviously more important than for something that serves only a limited number of users and can easily be fixed and maintained when in production. Good luck!

[rcallicotte]

Thanks otakar.  These are all good ideas, a few of which have been considered and implemented.  Great help.

[mr-miley]

calico. in my experience, functionality is functionality... As long as you test with a wide spread of data, by that I mean minimum, medium and maximum (with a few randoms thrown in for good measure) for each data type you should be fine. I definately agree with otakar. Test with end users if possible, and as much as possible, preferably the most stupid ones you can find (and I mean that seriously, they make the best testers, mainly because they do the unexpected, and in my experience, its usually the unexpected that breaks things). Just make sure you test with as much different data as you can. It doesn't matter if it's made up, as lond as it is representitive of its real world, actual use equivalent. I'll give you an example.... one of the data collecting fields needs to be a memo field (in MS Access terms, 65000 character max). Fire up word (or equivalent) do a good impression of a speed typisy, with your eyes closed. You can very quickly generate "words" of differing length, punctuation etc. Make 5 or 6 paragraphs of this, which should take about a minute or two, then just paste into your memo field, different paragraphs in different orders and different numbers of. Within 10 mins or so you could have "filled in" the equivalent of 10 to 20 peoples submissions, all with perfectly relevant data.

I maintain and develop a very specialised Geotechnical graphical database, and have been doing this to the same database structure for the last 12 years, and I still get the odd user from time to time coming to me and saying "I put this data in such and such field and it all went wonky". All down to them putting something totally unforseen in a field that was never intended to be used like this....this is what I mean about getting the  stupid ones to test for you....

[rcallicotte]

Cool, Mr. Miley.  LOL  I agree with you.  This is our plan, more or less.  I'll be relying on students...I'm not sure how smart or otherwise these Beta testers will be, so we'll see.  I won't get to choose my testers.