Test Automation tools are record and playback-style in Agile?
Since Agile is iterative and many test-last tools are record and playback-style, and therefore can't really be applied in an Agile environment, this brings up a few issues.
- the target for test is changing, rapidly - making it very difficult to automate
- by the time the target code has settled, the sprint/iteration is over, and you're on to new tasks (at least in the PM/BA's mind)
- resource management is difficult - 'if project A is 'done' (shipped) why are you now doing automation for it' may be asked.
What strategy can be applied in an agile environment to ease the pain of these moving targets / project-resource misalignment?
An answer - as Phil implied, is that you take every record and playback tool you can find, and burn them in a fiery pit of despair.
I probably got myself a down vote for that, so I'll try to earn it back.
Good Agile teams test constantly - not just at the end. If you include test design as part of feature design (and consider how the feature will be tested as it's designed), you won't have to write GUI automation - you can automate at the controller level, or through another abstraction.
Automating the GUI directly is rarely a good idea - even on "test-last" teams. Instead focus on what "quality" looks like for the feature, and work as a team to implement all of the tasks necessary to get to "done".