User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 5 of 5
  1. #1
    SQA Council
    Join Date
    Mar 2001
    Post Thanks / Like
    0 Post(s)
    0 Thread(s)
    Total Downloaded

    What is Data driven tests?

    User DAVID MARSH (DAVID.MARSH@thales-cs.com.nospam) posted:

    If you write a function to enter data into a screen or to capture data from
    If you write a set of functions to do this to all your screens.
    If you write some functions to navigate between screens.
    If you write some functions to pull data from a .txt or .csv file and use
    that data to drive the functions.
    And log your results to .txt or .csv files (so they can be used by other

    You will have basic data driven testing.

    Probably someone else will put it more eloquently, but the basics are there.


  2. #2
    SQA Council
    Join Date
    Mar 2001
    Post Thanks / Like
    0 Post(s)
    0 Thread(s)
    Total Downloaded

    Re: What is Data driven tests?

    User Torsten Zelger (torsten.zelger@obtree.com.nospam) posted:

    Here is an easy answer to the DATA-DRIVEN-TECHNIQUE

    Lets assume you have to test a website which accepts a search-string to be
    entered in the edit-field. You automate the test by writing a script which
    enters a simple text and verifies if the search-result fits your

    If you want to test the behaviour of the search-functionality with different
    kinds of search-strings you would change the script.

    A more elegant way is to put a set of search-strings into a datapool
    and repeat the same testscript with multiple and different kinds of
    search-strings (e.g. testing with special characters) which are all read
    from this one-and-only datasource (e.g. a database, excel or from

    In this case you can add an indefinite number of additional testcases



  3. #3
    SQA Council
    Join Date
    Mar 2001
    Post Thanks / Like
    0 Post(s)
    0 Thread(s)
    Total Downloaded

    Re: What is Data driven tests?

    User Dan Mosley (djmosley@csst-technologies.com.nospam) posted:

    Here are a couple of excerpts from our new book that describe data drive

    From Chapter One

    Powers (9) article "Styles for Making Test Automation work" which can be
    found on the "Testers Network" offers practical advice that software
    testing engineers who are responsible for building and implementing a
    test automation framework will find very helpful. It is includes
    common-sense discussions of programming style, naming standards and
    other conventions that should be applied when writing automated test

    There is a comprehensive discussion of the principle of data
    abstraction, which is the basis of the "Data Driven" approach to
    automated software testing. He discusses alternatives for coding how
    data are defined and used by the test script. According to Powers, "The
    principle is one of depending less on the literal value of a variable or
    constant, and more on its meaning, or role, or usage in the test." He
    speaks of "constrains for product data." He defines this concept as,
    "...the simplest form of this data abstraction is to use named program
    constants instead of literal values." He also speaks of "Variables for
    product data" and says, "....instead of the literal name "John Q.
    Private," the principle of data abstraction calls for the programmer to
    use a program variable such as sFullName here, with the value set once
    in the program. This one occurrence of the literal means there's only
    one place to edit in order to change it."

    The immediate impact of the statement Powers makes is that you begin to
    see the possible benefits derived from data abstraction when it comes to
    the maintenance of automated test scripts. He further suggests that
    these values be stored in a repository that will be accessible from the
    test script code, "All that's required is a repository from which to
    fetch the values, and a program mechanism to do the retrieval."

    This is the underlying principle of Strang's "Data Driven Automated
    Testing" approach (11). His approach uses a "scripting framework." to
    read the values from the test data repository. It uses a data file that
    contains both the input and its expected behavior. His approach has
    taken data abstraction from storing just the literal values to also
    storing the expected result values. This approach can accommodate both
    manual and automated data generation. The test script must be coded such
    that it can determine "right" results from the "wrong" results.

    Power's and Strang's work are reflected in the data driven approaches
    discussed in Chapter 7 and 8 of this book. Archer Groups Control
    Synchronized Data Driven Testing is an example of one such approach that
    employs the concepts discussed here.

    From Chapter Seven

    Data-Driven testing is a commonly used term these days. Most think of
    this as simply using external data as the source of input into the AUT,
    such as in the case where 'Data pools' are used. From our point of view,
    Data-Driven Testing is: Controlling the program flow and actions
    performed in a test script, with information contained in an input test
    data file. An input test data record is read from an external file or
    spreadsheet and is developed independently from the test script program.
    This idea has been further enhanced and modified by Archer Group and
    others. The methodology introduced here also employs the use of 'Control
    Data' to determine what actions are taken and in what order they occur.

    The Archer Group Framework

    The terminology Control Synchronized Data-Driven Testing (CSDDT) has
    been adopted to refer to this type of automated testing. Control
    Synchronized Data-Driven Testing specifies

    Where to go in the AUT
    What to do when you get there
    What to expect after the action is performed
    And what data is used for input or selection criteria

    The input test data records which are read by the test script should
    contain information that provides record level identity and control
    information such as:

    . Good input record, this may or may not cause an expected error
    . Skip this record, record data is bad or incomplete or is being
    used to comment following records
    . Breakpoint at this record, used for debug purposes
    . Perform special processing such as "keyword" substitution
    . Terminate the test before End Of File is reached.

    In general CSDDT directs test script navigation of the AUT, indicating
    what window / tab, child window, dialog box etc. is to be activated or
    selected. The data also specify what action is to be performed, such as:

    Select / Display
    Insert / Add
    Update / Modify

    Furthermore, the data also describe the expected results, whether or not
    an error condition is expected, and the type of Error. The data also
    allow comments to be included which makes the data records " self

    Last, but not least, the data records include the test data values that
    will be input to the AUT. CSDDT allows a variable number of input data
    fields. For example, one record could have as little as 1 data field and
    the next could have 31 or more data fields. The size should be dynamic.

    Using the CSDDT approach we have separated the tests into several groups
    according to test type. Each type corresponds to a unique automated test
    type and a specific class of automated test script drives each.

    . The GUI Test's purpose is to test test Window / GUI component
    . The Properties Test tests object properties of all windows,
    child windows, tabs and objects
    . The Special Features Test (when needed) test custom controls,
    features to be tested that do not readily fall into other categories,
    and may include special manual testing
    . The Data Base Content or Initialization Test ?????
    . The Business Rules Test tests client and server business
    rules/edits via data input and data controlled selections
    . Performance and/or Load Test (when needed)

  4. #4
    SQA Council
    Join Date
    Mar 2001
    Post Thanks / Like
    0 Post(s)
    0 Thread(s)
    Total Downloaded

    Re: What is Data driven tests?

    User (adrian.rutter@philips.com.nospam) posted:

    Might also be worth looking at Carl Nagle's DDE. I'm implementing it on my
    laptop at home.


  5. #5
    Senior Member
    Join Date
    Oct 2001
    Post Thanks / Like
    0 Post(s)
    0 Thread(s)
    Total Downloaded

    Re: What is Data driven tests?

    Here are some references: http://members.aol.com/sascanagl/Dat...mpilation.html

    [This message has been edited by sachinus (edited 08-12-2002).]
    Sachin Lalye



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 12.00%
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 07:26 PM.

Copyright BetaSoft Inc.