(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?

  • When kind of tests you want to perform? Functional, performance? What interfaces (e.g., Web site, SOAP Web service) you want to test?
    – dzieciou
    Dec 6, 2012 at 18:04
  • 3
    How are the devs testing their code, can they help ? Dec 6, 2012 at 18:13
  • 1
    Seconding Phil's question - I'd also ask whether your company culture would be amenable to long-term pairing (some places foolishly see it as waste). That would allow you to gradually increase understanding of testers, by pairing them with another tester who can already script.
    – testerab
    Dec 8, 2012 at 22:16

4 Answers 4


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.

  • +1 for the last paragraph. Forcing all testers to start automating is a great way to kill the spirit of some amazing testers. Dec 7, 2012 at 12:47
  • Agreed, people should always be doing what makes them happy.
    – Sam Woods
    Dec 7, 2012 at 17:15
  • 1
    Spot on with both the paragraphs. I used to work in a team where I was writing scripts and would explain certain sections to non-programmer QAs and do some parallel training and they were able to pick up, run and maintain the code. The mentor in this sense, would definitely need patience but it worked well to distribute the load. But first thing is they should have a desire to participate. Dec 7, 2012 at 18:41

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.

  • You can incur the expense of training some or all your team members.
  • You can replace some or all of your team members with people who know how to code test scripts.
  • You can split your team into coders and non-coders, and have the coders responsible for developing the test automation scripts.
  • You can develop a test automation framework. Often these invent a lightweight "language" that doesn't require any coding background. This approach usually requires one (or just few) people fluent in the scripting language. Often, the non-coders specify the tests using a simple Excel spreadsheet.
  • You can continue with your lighter-weight approach and avoid scripting as much as possible.

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.

  • 1
    +1 for DSLs (Domain Specific Languages - like Cucumber's Gherkin) that allow people to write scripts in English or near-English with code-behind written by a developer. Dec 6, 2012 at 19:32
  • 2
    I really do not like tools such as Cucumber. In my experience, they are just as difficult and proprietary to learn as actually writing automated tests in a programming language AND you still have to have a developer writing all of the automation code anyways.
    – Sam Woods
    Dec 6, 2012 at 21:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.