(Inspired by this question)
My team is currently doing automated testing via our tool's record-and-playback function. I've read about the benefits of developing a more robust test solution via writing our own scripts, but some of our team members do not come from a programming background and training them can be rather expensive. How can I ease this transition?
The more programming-experienced testers may be able to write a framework that makes programming easier for less programming-experienced testers. I cannot describe specifics about the framework because it will depend on your own circumstances, but if your testers have experience with programming, they may already understand how that process works.
Are you sure you want everyone on your team to switch to scripting? And are you sure everyone on your team wants to switch to scripting? I have never worked on a team where everyone relied on record-and-feedback or, for that matter, on any kind of automation. Often there are some people who are not a good fit for programming. Those people can still be effective testers.
if you have read my answer in the question you linked to it gives some examples of how to simplify your automation code and make it more maintainable and reliable. Teams I have worked on have often split the work, with more experienced developers working on the page objects and helper functions and less or completely inexperienced QA folks working on the test cases themselves.
There is a learning curve, but to write a test case in an IDE with intellisense against an existing library of pages and helper functions is actually pretty easy even for a non developer to pick up with a little bit of documentation and training. I know this because I have had people in that position many times and they have always been able to get up to speed and help contribute to the automation efforts. As a side benefit, they get exposure to a programming language (at least the basics of it) and from there they can and often do continue to learn and gain more skills over time.
As Phil mentions, you can even recruit developers to help with the more complex parts of your automation if nobody on your team has the skills necessary.
There are several solutions.
On my team, I like to have everyone capable of writing and executing test automation. While we sometimes use recording to form an early draft of our scripts, we then enhance them to be more robust. This requires at least some use of the scripting language itself. With a few experts on the team, the rest can get help as needed to enhance their automation.
There are tools out there that abstract away the need for specific coding knowledge in order to develop a script. My team uses a proprietary tool called TMX by Critical Logic, but I've also used Cucumber in the past for this sort of thing. The basic idea is to have one person able to develop and automate scrips while another handles writing the required framework methods to support the test.
With Cucumber, the most the automater would have to write is plain English sentences like "When I press submit, then I should be on the Record Submitted page and I should see my new record in the table". Meanwhile, another team member handles writing the code that determines what it means to see a record in the table. That way everyone does what they do best.
Using TMX, the coders would define specific actions or procedures, each with a block of code attached. The automater then uses the GUI to define the sequence of actions a test will perform and presses "Generate", which produces a script file all ready to be executed. We use it to produce Java code, with each action being generally one method call against our framework library.
I'm sure there are more tools out there, but I don't have personal experience with any others.
