Rolling out Selenium effectively is not as simple as just installing it and writing a couple tests. I think some of the disappointment when rolling out any automation platform is due to not accurately identifying the audience of the tool. The audience for Selenium and similar things can be broadly broken down into technical and non-technical and each has an implementation focus.

Technical

When the audience is technical in nature, you can throw a collection of api docs and some examples and they’ll figure things out so ease of use is less important. You can’t totally neglect it, but rough edges are ok. Implementation and and rollout details should then focus on building a driver that suits your situation.

You could for instance, build yourself a nice metaframework to run tests in all the languages your developers write. I had one at a previous company which could run Java, Ruby and Python tests and report the results in a single commands. Also important here are helper methods to allow for modular script design.

No one at this point is going to confuse what they are doing for anything but programming.

Non-Technical

Inevitably, someone gets the idea that that the analysts or non-technical members of the test group need to be doing automation. Out of the box, this is a recipe for fail. Especially with frameworks like Selenium. The way around this is to wrap the low-level Selenium calls in higher-up methods. In the current jargon, this is called a Domain Specific Language (DSL). The script creator then uses this DSL. In theory, they should be able string together a bunch of commands like

<pre lang="text">login(user, password)
mortgage = new_mortgage(300000,6.35,25)
fund_mortgage(mortgage)
mortgage.should_have(300000)

Or something similarly abstracted.

This takes a lot of work by the technical group (working with the non-tech’s to understand what they need abstracted; and how). This causes an optics problem as management will be asking (nagging, pressuring, etc.) what you are doing and when the savings from automation will start to be felt.

Satisfy both?

With either audience, there is work necessary from a technical group. I suggest then that you target the technical group first then. This shortens the time before something can be shown to management. Only after you have the ability for the technical members of the group to write tests should you add support for the non-technical ones.

Another benefit of this ordering is that naturally occurring patterns and tasks will appear. These will form the basis of your DSL.