The Myth of the Automatic Automated Benefit
Tuesday, March 31st, 2009 by The DirectorScary Tester does a good bit of putting a positive spin on when it’s best to do automated testing:
Automated tests are suitable for the following purposes:
– Regression testing for a stable system that will be run on a regular basis
– Fast data creation in test systems where the database must be wiped on a regular basisAutomated tests are NOT suitable for the following purposes:
– Testing new functionality – this should be done manually before automated tests are created
– Regression testing systems that are expected to have significant user interface changes. Large changes to the user interface require a lot of maintenance for automated tests.
You know, testers make these arguments over and over again, but I’ve gone into a number of places to talk about starting QA efforts on major product lines or to work on smaller (160 hour) projects where the principal involved wants automated testing. Usually on an evolving product and with only one QA person. Try as I might to dissuade them, they go out and find someone willing to bill them less fruitful hours of QA work because that’s what the client wants. And the client/employer gets it: an automated effort of some sort, a low defect count (because the QA person spent hours selecting/writing/maintaining automated scripts instead of testing.
But Scary Tester’s and my commentaries fall on sympathetic ears. Meanwhile, Baseline magazine will run a bunch of ads from software companies selling automated testing software and amid a splashy article about how automated tests can do the work of 20 monkey testers.
I think I’m repeating myself, aren’t I?