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?

How are the devs testing their code, can they help ?
–
Phil KirkhamDec 6 '12 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 '12 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.
–
Lyndon VroomanDec 7 '12 at 12:47

Agreed, people should always be doing what makes them happy.
–
Sam WoodsDec 7 '12 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.
–
Suchit ParikhDec 7 '12 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.

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 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.
–
Ethel EvansDec 6 '12 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 WoodsDec 6 '12 at 21:01