SPONSORS:






User Tag List

Results 1 to 4 of 4
  1. #1
    Senior Member
    Join Date
    Jul 2000
    Posts
    117
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Totally Data Driven Testing - thoughts / questions

    First, I've read the extremely informative thread from about a year ago (started by "Lena", and including responses from KeithZ, Steve Mayes, Terry Horwath, and Rick Weth).

    So, here we are a year later, and now I want to head down this path with Silk. OK, it may not be perfectly suited (as well suited as VT or WinRunner ...) to the task, but I'm hoping that other folks have tried some things and have some "secrets" to share.

    First, the app I'm going to test is almost entirely Browser based. There are a few native Windows components, but the interaction there is limited - hence I wasn't planning to do much in the way of window decls anyway. I'm planning to combine the "aeweb3.inc" with my own "enhancements" and use that as the basis for most of the window interaction.

    My questions, though are:

    1) Has anyone found a nifty design pattern for addressing logging? Specifically, since I won't have "unique" testcase declarations (everything is run as a function ... right?), what's a good way to capture the "real" testcase name, and hopefully log it using the new database logging stuff in Silk? I confess I haven't spent a great deal of time messing with this area -- thinking that it's a wheel that's already been invented.

    2) Anyone care to share thoughts about the relative merits of completely wrapping window objects in functions vs. having the engineers "code" window objects in the "spreadsheet"? That is, using "DisplayMenu()" vs. Browser.MyPage.Object.Click().

    I know what you're thinking -- you're thinking, "sheesh, that's all the issues he's found!?", well, no, but since I have a chance to "do this framework right" from the start, I want to consult the collective wisdom of the group so as not to make silly mistakes early.

    I know that the technical problems are mostly solvable -- I'm just looking for ideas / experiences that will help me, and in turn all of us, in the future.

    Thanks!

    ------------------

  2. #2
    Senior Member
    Join Date
    Nov 2000
    Location
    Bloomington, IL
    Posts
    142
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Totally Data Driven Testing - thoughts / questions

    I create all of my scripts to be data driven. I work with browser based applications primarily. I create no testcases, everything is a function.

    I am not sure why you think that working with browser based applications that you do not need to record window declarations. Window declarations are what give the scripts a basis.

    1. I record window declarations for every window I use in my script.
    2. Then I go through tand develop a "happy path" set of functions. Each function lets me enter the required information for a specific screen and move to the next screen. This allows me to go back and create specific error functions for each or multiple screens.
    3. I then create my input functions. I use a database connection because there are usually more problems using text or Excel input files. The first function connects me to the database. The second executes the SQL and fetch next. The third function divides the data into the variables to be used for data input.
    4. I then create a .t file and reference the .inc file with a use statement. I create a Main function and call the other functions from here.

    All of my functions operate within a do..except statement. This allows you to raise errors to the Main function and handle them all from one error handler, or if you know that the function you are calling will create an error, you can handle it and return the application back to a usable state. This allows you much flexibility then returning to the basestate.

    Using this type of setup with SilkTest I have been able to create about 60 reusable functions that makes coding easier and faster.

    I don't know if this will help at all, but you never know.

    MikeF

    ------------------

  3. #3
    Senior Member
    Join Date
    Jul 2000
    Posts
    117
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Totally Data Driven Testing - thoughts / questions

    Good starting point, MikeF!

    I should probably have clarified that, yes, there will be some window declaration for those pages that are "mostly static" -- the application we are testing has a highly dynamic, interactive "grid" component that is NOT an HTML table -- so a lot of what I need to test is really a case of finding link X, clicking it, and moving on. It's a long story -- but I get your point and I'd agree with it.

    I'm also with you overall on the design of your framework -- but how do you handle results logging? As I look at the example ResultsLogging repository files that come with Silk 5.5, they make a call to GetTestCaseName() in order to store that info in the appropriate table. From what you've described, there won't be a testcase name defined -- at least not in Silk's definition.

    I'm assuming you did custom logging in the .res file.

    Once again, yes, I can modify the daylights out of the "stock" Silk code to address this, but was hoping to avoid those kinds of mods if I could. Makes for tricky future upgrades ...

    I could also write custom DB logging routines and just "inject" them into the appropriate places in my own, over-ridden TestCaseEnter() / TestCaseExit() / etc. functions.

    Again, looking for some experiences that others might have had in this area.

    Thanks again, MikeF for at least validating that I'm starting down a reasonable path!


    ------------------

  4. #4
    Senior Member
    Join Date
    Nov 2000
    Location
    Bloomington, IL
    Posts
    142
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Totally Data Driven Testing - thoughts / questions

    I did no custom logging to the .res file instead I output my errors to a database table. This is easier to handle and allows you to trace your errors. When I did output errors to something other than the database I use a .txt file (FileWriteLine). This format can be read by tools other that just SilkTest.

    We are not talking about lots of tricky code here. Just create the functions you need, make sure they are not to specific (pass values) and they are easy to maintain and upgrade if you need to later.

    MikeF



    ------------------

 

 

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 08:54 AM.

Copyright BetaSoft Inc.