Automated GUI testing in agile
Posted by Stan Taylor on March 19, 2008
Recently, I've had several conversations at work about the cost/benefit analysis of performing automated GUI testing (in our case, using Borland SilkTest, of course) in our agile environment.
In general, automated GUI testing is most useful in the following situations: when the UI of the application under test (AUT) does not change much, and when there is significant regression testing to be done--where the time commitment of creating and maintaining automated tests is lower than the time commitment of repeating manual regression testing.
I've been working with an agile team that is in the first few sprints of a new product; this product's UI is still changing frequently at this point and the product does not yet have much functionality for regression testing.
So, we have a resource allocation dilemma: this team would not benefit particularly from automated functional testing at this time. However, in, say, a year, when this product is more mature, automated UI tests would be very beneficial. But if we wait until then to start automating, we'll never get caught up, so we need to start devoting steady effort to the automated testing soon.
In an agile environment, it's difficult to get resource commitments for efforts that only have long-term results.
I'd love to hear whether others have faced this same dilemma and how you dealt with it.
Comments
Interesting blog, it's great that you're sharing your knowledge on the subject !
Posted by: A. Apolskis | March 19, 2008 02:22 PM
Did you ever get any responses to this question outside of this blog?
Posted by: justmy2 | July 13, 2008 08:45 PM