cartmen34

I wasn't sure if this should go in Computers, programming, or living.... I guess here is just as good as anywhere else. It's not really a specific programming question, but oh well. Mods, sorry if this is in the wrong place.

So anybody here a software automation engineer/tester? Do you use QuickTest Pro? If not, what automation software do you use? what are you opinions of the software, whatever that software may be?

I've been using it on and off for about a year now, and I've found the experience....interesting....to say the least. I've tried my best to use the built in record/replay technique, but I've found both it and the Object Repository to be, well, god aweful-nasty-bad-nasty to use. I've resorted to descriptive programming to perform events on objects. Time consuming, but easier in the long run.

Anybody? Any thoughts? Comments?

__________________
"The problem with quick and dirty, as some people have said, is that the dirty remains long after the quick has been forgotten" - Steve McConnell

gh0ti

I'm an ASP/VBScript developer. We are lucky enough to have a Quality team that goes through and tests our code before we release anything to our customers/employees. The Quality Team basically goes through a spec line by line and tests each item to make sure it works correctly.

I'm of the opinion that "humans do it better". While I can honestly say that I've never worked with a QA automation application, I kind of wonder if you would spend to much time developing the app and then developing a test for the development process once your done developing (if that makes sense) .

One of my QA guys happened to walk by as I was writing this and he has actually worked with Mercury products before (he basically agrees with my opinion). It’s much better to have a Functional Specification down on paper. The developer develops from this spec and the QA guy tests the code from the same spec once the code is written. Spending the time to develop a testing script after the code is written just seems to add more time to get the final product out.

I’m kind of curious to see if anyone has had a good experience with it though. In a smaller company where resources are more important then time I could see where this could be useful.

__________________
I ain't often right but I've never been wrong
It seldom turns out the way it does in the song
Once in a while you get shown the light
In the strangest of places if you look at it right

cartmen34

You should consider yourself very fortunate to work for a company that values white-box testers and uses them to the fullest extent possible. (That's the "official" name of the kind of testing you describe.)

I would agree with this to an extent. When you have unchanged code that needs to be tested with each build release, automation can save hours, even days of manual testing. Automation also offers a small amount of precision to repeated black-box testing, as manual testers may sometimes "skimp" on repeated tests, because, well, "it's been tested 100 times already, why check it again?"

However with a constantly evolving product, this can be impossible to effectively implement. It all depends on the situation and the company's strategy.

I would also agree with this. As a professional tester who's been in just about the worst development enviroment ever, where we were required to test an undefined, unspec'd, moving target of an app, I can attest to the benifits of a good functional spec.

__________________
"The problem with quick and dirty, as some people have said, is that the dirty remains long after the quick has been forgotten" - Steve McConnell