I'm so impressed with Selenium. The browser integration and the IDE true/false makes it very easy to set up and use. I literally got it working in about ten minutes. I had a couple of bugs from QA, so I used Selinium to record their replication in my dev environment, then switched a couple of attributes from "off" to "on" to represent what the code *should* do. And now I'm back to automated test-first programming.
I see that with the Selinium RC server, I could actually run these things as Junit tests, or I can run them with the selinium suite. I'm torn as to which way I want to go. Obviously, recording them via the Selinium IDE is the way to start, but being able to make modules in Java code sounds pretty powerful. Once you go to Java, though, you don't go back to the IDE, so I'm worried that will make it less flexible in terms of using selinium tests to communicate with the QA department.
I'm sure that the QA department can learn to use this tool -- they've learned far more byzantine automation tools in the past. A frequent problem we have is in communicating with the folks that do our acceptance testing. They're a hand-picked subset of our actual users, and it's often difficult to communicate unusual situations. The type of bug reports we are typical of non-technical bug reports, basically "got this error" without a lot of information of what happened before the error happened in the first place. That's not their fault -- they're likely not thinking about what they've done before, and in many cases the problem is so complicated or convoluted that they can't realistically be expected to remember.
The thing I'm really wondering is if Selinium is simple enough to be used by our acceptance testers to help articulate what they're seeing. Could we really ask them to just record their session, and playback their experience? That would be pretty exciting.
No comments:
Post a Comment