| I'll add one example from a past company I worked for: - We had a manager and one internal developer assigned part-time to an effort to seed an automation effort. - The front-end of the application was Flex. - Most QA analysts at the company had never written code before. - We attempted to use Selenium. As you can imagine, this was a crash and burn for several reasons. The company couldn't get enough buy-in internally to dedicate more developer time to seed the effort, and the long-term approach was not well thought out. A few tests were deployed, but they were brittle because they relied on DOM elements. This was partially because QA analysts were expected to be able to use a Selenium "capturing" tool to create tests without writing any code. Writing this out now, I think the root problem is that at the management level, the sentiment was just that we should "do automation" and no one really understood how much that would involve. There doesn't seem to be any turn-key solution out there that is designed to fit in with the rest of a company's development processes. When there isn't a clear path for solving a problem, it becomes a much more expensive problem to solve. In this case, the cost far out-weighed any benefit that the company would see. With that said, I am still optimistic about the potential for effective UI automation testing and I'd love to hear more stories. |