SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 6 of 6
  1. #1
    Junior Member
    Join Date
    Mar 2006
    Location
    Knoxville, TN
    Posts
    6
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Opinions Requested: Need for Whitebox Backend DB Testing...

    Here's the sitch:

    The web application we test has a SQL backend. The developers are using ASP.NET 2.0 technology, so the web page controls are directly bound to the SQL DB via stored procedures or SQL statements associated with each control.

    My boss (the Chief Architect/Development Manager) said that the test team doesn't need to do any backend verification of data because of this architecture -- basically, that we can assume that if our inputs in the web forms are redisplayed correctly after saving/editing/etc., then we've also verified the stored procedures and functions.

    My concerns are:
    1) How will we know that we're "covering" the DB adequately (meaning how do we know we're really executing all stored procedures, functions, etc. with our set of test cases)?
    2) Is it really that safe to assume that the data is correct if it's correct in the GUI?

    I would like some opinions -- am I just being paranoid, or is there some validity to my concerns? Thanks so much.
    ~Marisa Seal

  2. #2
    Moderator
    Join Date
    Mar 2004
    Location
    West Coast of the East Coast!
    Posts
    7,756
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Opinions Requested: Need for Whitebox Backend DB Testing...

    First of all, If I understand your question, back-end white box is definitely not needed. This would imply that you want to work with the application behind the db itself. in my experience the general method of testing is from the front-end with some SQL queries to validate functionality. But if your front-end also outputs data reflective of all of the inputs then, unless there is concern for a specific functionality of the DB which is not reflected on the front-end, there is no reason to run the SQL queries either. In order to be sure the DB is covered thoroughly, you must insure that your test coverage is as complete as possible. If you duplicate any input or condition that the user can possibly perform as well as the environment, (type of PC, type of browser, type of interacting applications, etc.), then your coverage should be adequate.
    Personal Comment

    Success is the ability to go from one failure to another with no loss of enthusiasm.
    ~ Winston Churchill ~


    ...Rich Wagner

  3. #3
    Moderator Joe Strazzere's Avatar
    Join Date
    May 2000
    Location
    USA
    Posts
    13,170
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0

    Re: Opinions Requested: Need for Whitebox Backend DB Testing...

    Originally posted by Marisa Seal:
    My boss (the Chief Architect/Development Manager) said that the test team doesn't need to do any backend verification of data because of this architecture -- basically, that we can assume that if our inputs in the web forms are redisplayed correctly after saving/editing/etc., then we've also verified the stored procedures and functions.

    My concerns are:
    1) How will we know that we're "covering" the DB adequately (meaning how do we know we're really executing all stored procedures, functions, etc. with our set of test cases)?
    2) Is it really that safe to assume that the data is correct if it's correct in the GUI?

    I would like some opinions -- am I just being paranoid, or is there some validity to my concerns? Thanks so much.
    <font size="2" face="Verdana, Arial, Helvetica">Hmm... no backend verification at all?
    Seems like an odd statement to me.

    How will you know that the data is actually being stored in the expected fields?

    The UI could allow entry of data, and re-display it perfectly, yet place the data in the wrong place. The application might work ok, until someone decides to add a new report and finds out that data isn't where it is expected to be.

    I might be able to understand the lessened risk of not validating the back end. But I'm not sure I'd agree that it could be completely ignored.
    Joe Strazzere
    Visit my website: AllThingsQuality.com to learn more about quality, testing, and QA!

  4. #4
    Moderator
    Join Date
    Nov 2001
    Location
    Greater Boston Area
    Posts
    1,026
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Opinions Requested: Need for Whitebox Backend DB Testing...

    Adding to Joe's response, what if there are tables that store static data separate from the application's tables? How would that be tested if only front end testing is done?

    Also, there are tables dependent on values of other tables that may not be visible as well.

    I would ask your team leader/manager if there are known dependencies within the database that are not visible to the web application. Does the web application's database populate any other database and/or database server?
    Going out of your comfort zone requires failure. True genius is measured by your recovery.

    ...Jean Ann
    www.perfectpitchmarketinginc.com
    http://on.fb.me/PPM100
    www.projectrealms.com/

  5. #5
    Junior Member
    Join Date
    Mar 2006
    Location
    Knoxville, TN
    Posts
    6
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Opinions Requested: Need for Whitebox Backend DB Testing...

    Thanks everyone for your input. I will discuss this further with our DBA.
    ~Marisa Seal

  6. #6
    Moderator
    Join Date
    Sep 2001
    Location
    Yankee Land
    Posts
    4,055
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Opinions Requested: Need for Whitebox Backend DB Testing...

    When I worked at a place where we had ASP on IIS with an MSSQL backend there was this kind of thinking as well. Still being the trustworthy soul that I am what I did was make "Verification Scripts" that I would run on a set number of cases that had inputs into various tables. The "Verification Scripts" were nothing more than queries that would display the data we input depending on the table we wanted to check. Since our app mostly dealt with a few specific tables we concentrated on those, the other tables we would cover with fewer test cases.

    This allowed us as well to have some scripts we could use to check on Production problems, occasionally I or someone on my team would get a question about a Customer issue. Knowing what they did also allowed us to try and replicate it, and use our scripts to make sure the data went to the right tables. Knowing the dependencies also helped, as there were stored procedures that would move data around, or archive data at certain times, so we would bring in the DBA to understand the schema as well as stored procedures and views. If you have searches happen, then you have views that the pages need to display data from.

    The problem with your Chief Architects position, is that with the test methodology he advocates you are using the application to test the application. That does not always work, because you have no independent verification of the data structure on the back end.

    I had toyed with the idea of using some scripting to run the database through, sort of like a SQLUnit test or something. But never had time to get it implemented, ask your DBA if they have something like that.

    - M
    - M

    Nothing learns better than experience.

    "So as I struggle with this issue I am confronted with the reality that noting is perfect."
    - Unknown

    Now wasting blog space at QAForums Blogs - The Lookout

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Search Engine Optimisation provided by DragonByte SEO v2.0.36 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 9.68%
vBulletin Optimisation provided by vB Optimise v2.6.4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.2.8 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominate (Lite) - vBulletin 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 03:51 AM.

Copyright BetaSoft Inc.