> One of the "philosophers' stone" goals of the software industry is to completely replace human testing with automated testing.
Generally the people who say that don't have a clue - I meet them monthly: "We can save X money by writing a Selenium script and firing the whole QA team!" is typical.
I'm managed QA teams at a few companies in telco, boxed software and SaaS.
And people invariably get all huffy when I say, "Are you going to assign one of your programmers to review changed screens before integration and deploy?"
Then suddenly their eyes glaze over since they just lost a partial headcount and accepted even more responsibility for the release.
What I want are world-class manual testers that understand all of the product features, know how to approach testing it, what the problem areas are, and can communicate the issues to developers.
Luckily I know a few, and I wouldn't call what they do "monkey-testing" at all - their opinion of a release's quality is the only one that actually counts to me.
What I don't want are programmers writing Selenium scripts with no understanding of the product, then moving on to some other project and abandoning half-done tests. That's what you get when you fire your QA team.
> I've always thought that the engineers in QC should be just as skilled and qualified as the ones building the product.
World-class QA people are skilled at manual testing. World-class automated test programmers are not QA, they're called programmers.
For developers, what you can do is make the software you write testable. For web applications, add id's to all buttons for example, which are usually required for automated testing software to know what to specify.
Also, if you crapped out a feature (did a copy and paste of other code with "it works for me" local testing), just tell your QA person, "I crapped it out. Please take a look." so they know they'll need extra time to look at it.
Generally the people who say that don't have a clue - I meet them monthly: "We can save X money by writing a Selenium script and firing the whole QA team!" is typical.
I'm managed QA teams at a few companies in telco, boxed software and SaaS.
And people invariably get all huffy when I say, "Are you going to assign one of your programmers to review changed screens before integration and deploy?"
Then suddenly their eyes glaze over since they just lost a partial headcount and accepted even more responsibility for the release.
What I want are world-class manual testers that understand all of the product features, know how to approach testing it, what the problem areas are, and can communicate the issues to developers.
Luckily I know a few, and I wouldn't call what they do "monkey-testing" at all - their opinion of a release's quality is the only one that actually counts to me.
What I don't want are programmers writing Selenium scripts with no understanding of the product, then moving on to some other project and abandoning half-done tests. That's what you get when you fire your QA team.
> I've always thought that the engineers in QC should be just as skilled and qualified as the ones building the product.
World-class QA people are skilled at manual testing. World-class automated test programmers are not QA, they're called programmers.
For developers, what you can do is make the software you write testable. For web applications, add id's to all buttons for example, which are usually required for automated testing software to know what to specify.
Also, if you crapped out a feature (did a copy and paste of other code with "it works for me" local testing), just tell your QA person, "I crapped it out. Please take a look." so they know they'll need extra time to look at it.