Agile Test Automation
Principles of Test Automation
Test automation is vulnerable to instant obsolescence.
Software projects revolve around production code. Test code is not production code. So the priorities of a typical software project allow production code to change even when that breaks test code. This is normal, and generally speaking it’s a reasonable, economically justified behavior.
Assuming that the product will change, you have basically two options: invest in test code to be robust in the face of such change, or make test code so inexpensive and easy to fix that you don’t mind if product changes break it.
Test automation cannot duplicate human testers.
Human testers, even ones who have no special skill or training, are capable of doing and noticing things that no conceivable test automation can do or notice. It’s true that, even with its limitations, automation can have substantial value. But, it’s usually more productive to think of automation as extending the reach of human testing, rather than replacing it. Effective automation efforts therefore begin with effective thinking about testing. Absent good test strategy, automation typically becomes just a lot of repetitive activity that rarely uncovers a bug.