SPONSORS:






User Tag List

Results 1 to 4 of 4
  1. #1
    JQ
    JQ is offline
    Junior Member
    Join Date
    Jan 2000
    Location
    Maynard,MA,USA
    Posts
    16
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Verifying Back End Data

    Hello. I have an idea I'd like to bounce off you chaps....

    The problem at hand is how to verify the data residing in the back end database. Scripts can enter data in one format, and the client app will store the data in a different format in the database. Also, the format may change due to the datatype defined for the destination column. Another variable is no data at all. An Email field may be empty, thus a NULL or zero is stored in the table. So I need some decision logic like "if input data exits, verify it, otherwise use the table default."

    So after messing around with data structures (LIST OF whatever) and functions, I still could not come up with a consistent way to verify the data. So how about this:?

    Create a custom table object for each table in my back end DB to serve as an interface between the verification code and the DB interface. I figure I can create methods and properties for each column (child) object to format the returned data, and supply the scripts with datatypes and default values for each column of the table.

    Has anyone taken this approach? Is there a more simple, elegant way to deal with this problem?

    Thanks,
    JQ

  2. #2
    Senior Member
    Join Date
    Aug 1999
    Location
    Cambridge, UK
    Posts
    470
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Verifying Back End Data

    We had this problem some time ago; we decided that the best thing to do was to redesign our tests in order to make the database checks easier. What we did was this:
    - define a record (type ... is record) for each database table, with field names and datatypes corresponding.
    - Have the scripting functions which deal with inputting data into the app, work from data defined in these structures. This is slightly more awkward than having a variable corresponding to each control on your window, but we found it to be possible with a bit of tweaking and calculation here and there.
    - Define a function which can take as input one of these data structures, do a sql query to get the data from the table, and compare the two.
    Note the benefits of this:
    - All your testing becomes organised around the data you are inputting into the app; as everybody keeps emphasising, data-driven testcases are a good thing.
    - The cases of null or empty database fields is dealt with as just one of the possible values in your data record. Verifying that a null or empty value has been recorded can be just as important as verifying any other value.
    - This testcase design lends itself well to expansion, for example where a new module of your app contains new database tables. Just define the record for your new table, and the existing database verification function will be able to cope with this.
    Disadvantages:
    - redesigning existing testcases to work with the new data structures.
    - Featurs of your app which don't write to the database are easy to neglect while getting all the database verification stuff sorted and working correctly.

    But it's worked for us, and it has turned out to be the testcase redesign which was genuinely lasting and has proved it's worth. (we've done a few over the years).

    Vince
    vince@jobstream.co.uk

    P.S. If you are interested in this kind of solution, drop us a line and I can fill you in with some of the details of how we implemented it.

  3. #3
    JQ
    JQ is offline
    Junior Member
    Join Date
    Jan 2000
    Location
    Maynard,MA,USA
    Posts
    16
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Verifying Back End Data

    Thanks for the reply. Your approach sounds pretty similar to what I have thought about. The difference being that I was considering using a table object instead of a data structure. After experimenting with this approach, I decided to use a less complicated approach to start. (this is a new autotest effort) What I was trying to achieve was a way to build in some inteligence into the test infrastructure that emulated the functions of the client app and back end database. I'm not sure this is a good thing to do so I'm going back to basics, so to speak. I will supply my scripts with input data, and expected result data. The scripts will simply operate the GUI and then compare the resulting data to an expected result set. This should serve me well for the time being.

    Thanks again.

  4. #4
    Member
    Join Date
    Feb 2001
    Location
    New York, NY
    Posts
    41
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Verifying Back End Data

    I am using the similar approach as Vince, for Back end testing. Basically:

    1. Create "type ACCOUNT is record" for each database table.

    2. Assign data to record from the test plan.

    3. Read the data from the table, and save it to the file.

    4. Compare data in another table to the data in the file from step 3.


    Here is my problem, the step 4 takes too long. So far I did not find any quick way to compare two records. Is there any data structure that I can you for it? Any help will be appreciated.

    ------------------
    -Lev Aks
    lev_aks@in-nyc.com

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.0.9 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Questions / Answers Form provided by vBAnswers (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominatevBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 02:28 PM.

Copyright BetaSoft Inc.