Quote:
|
Originally Posted by 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.
|
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.)
Quote:
|
Originally Posted by gh0ti
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)  . |
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.
Quote:
|
Originally Posted by gh0ti
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 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.