|
Author
|
Topic: How Many Of You Are Using Table/Keyword-Driven Methodology?
|
pcl9097
Member
Posts: 14
Registered: Jan 2002
|
posted 06-13-2002 08:28 AM
    
Just wondering what you guys are using your automation tool for. Are you simply using it as a record/playback? Data Driven? or Table/Keyword Driven? It doesn't seem like there is a lot of discussion in these forums on Table Driven methodology. Thanks ------------------
|
jstrazzere
Moderator
Posts: 2134
Registered: May 2000
|
posted 06-13-2002 09:00 AM
quote:
Originally posted by pcl9097:
It doesn't seem like there is a lot of discussion in these forums on Table Driven methodology.
???
I don't think you are reading or searching here enough.
There have been many discussions. I'm not using such techniques, but I have in the past.
Do you have a specific question? ------------------
- Joe (strazzerj@aol.com)
|
turbotester
Guru
Posts: 375
Registered: Dec 2001
|
posted 06-13-2002 06:22 PM
I have asked this question myself as I built my own engine with a pretty nifty front-end for newbies - what are you looking for?------------------
www.turbotester.com
|
Rayr_UK
Advanced Guru
Posts: 407
Registered: Apr 2000
|
posted 06-14-2002 02:49 AM
Hey turbo reply with your utility attached I would like to have a look at that!------------------
|
Valberg
New Member
Posts: 2
Registered: May 2002
|
posted 06-14-2002 03:26 AM
We are working on an 'TestPartner command' + 'Excel data depository' solution for data/keyword driven test. It will make non-technical personnel able to create ATs. But I fear there might be a maintenance problem when we turn 2000 scripts.------------------
|
Testy
Member
Posts: 93
Registered: Apr 2002
|
posted 06-14-2002 07:16 AM
We are using a keyword-driven approach for testing of a large web app for a federal agency. Actually, a keyword-driven harness is much easier to maintain. The only drawback may be the time needed to develop the framework, but once it is up and running it's pretty easy to use. But I fear there might be a maintenance problem when we turn 2000 scripts. Well, the scripts are really keyword tables. Keyword tables are much easier to maintain than TSL scripts. What kind of information are you looking for specifically? ------------------
|
pcl9097
Member
Posts: 14
Registered: Jan 2002
|
posted 06-14-2002 07:33 AM
I'm glad to hear some of us are using the Table Driven approach. I find myself ready to do the difficult part (the actual scripting of the harness and keywords).I guess what I'm looking for is people with experience in this approach, perhaps they wouldn't mind sharing their experiences. The tool of choice for me is WinRunner. To say it in the simpliest form, is it generally numerous CALL statements and excel data tables? Thanks for the info. ------------------
|
e-tester
Guru
Posts: 216
Registered: Aug 2000
|
posted 06-14-2002 08:17 AM
For those of you using Rational you might want to check out this site.For those of you that are not you still might want to give it a look just for the information about a keyword approach that is there if nothing else. ------------------
ER,
Sr. QA Lead
|
zool_42
Member
Posts: 9
Registered: Oct 2001
|
posted 06-14-2002 11:48 AM
I'd also greatly recommend Carl's DDE as posted in the previous reply. If you are using Rational, and want to deploy a table driven approach, then it's pretty much a no-brainer in my opinion. Carl's done all the work for you.------------------
|
Semantec
Member
Posts: 35
Registered: Feb 2002
|
posted 06-17-2002 03:38 AM
quote:
Originally posted by zool_42:
I'd also greatly recommend Carl's DDE as posted in the previous reply. If you are using Rational, and want to deploy a table driven approach, then it's pretty much a no-brainer in my opinion. Carl's done all the work for you.
Hi Zool
I am thinking about integrating Nagle's DDE into my Rational automated scripts;in my point of view using frameworks like DDE is the only way to create reusable scripts that do not die after a few code changes..Do you have any real-world experience with DDE?
If anyone has experience with DDE ( or similar) - please share it with me on my mail
plamen_cog@yahoo.com ------------------
|
louadornato
New Member
Posts: 3
Registered: Aug 2001
|
posted 06-20-2002 08:57 PM
quote:
Originally posted by pcl9097:
I'm glad to hear some of us are using the Table Driven approach. I find myself ready to do the difficult part (the actual scripting of the harness and keywords).I guess what I'm looking for is people with experience in this approach, perhaps they wouldn't mind sharing their experiences. The tool of choice for me is WinRunner. To say it in the simpliest form, is it generally numerous CALL statements and excel data tables? Thanks for the info.
I wrote one from the ground up for testing an industrial inspection robot. I started with National Instruments Lab Windows (which is actually a pretty good package) because it worked well with the I/O chards I was driving, but I'm now completing a version that uses the MFC (for my money, much harder to use, but somewhat more flexible).
I'm of the opinion that there are always a few tests on any project that can't easily be adapted to the Table Driven approach (just as there are always a few manual tests that can't be automated at all), so I also made the I/O channels and results logging functions available to external languages through a "regular" DLL. This means that you can also write and debug test programs using VB or C++ right in the Visual studio IDE. One point that I've thought over long and hard - should I add flow control keywords (if/then, for/next, do/while, etc/etc.) to the spreadsheet? It would be trivial to add this, and you know there will be customers who will ask for it. After a lot of agonizing, I've come to the conclusion that this is a Bad Idea. If you add flow control, it's inevitable that some people will start out with a "simple" test, and then try to extend, expand, and tweak it far beyond the capability of the table-driven capability to handle. By the time they finally admit that they should have written the test in VB or C, they've wasted a man-week or more. Since my whole objective was to make the testing system more effective, it seemed pretty obvious that the best bet was to leave the flow control out. ------------------
|
