We are planning on integrating/developping automation solution with Webdriver 2.0 for our web application.

We currently have 2 members in the team that can write code, and understand enough Java to work with Webdriver.

But we also have 4 members that never wrote a single line of code.

Did you ever see such scenario? What kind of task a non-programer could do in such environnement?


  • Hi @david-plante - welcome to SQA! I'd like to answer, as at my current company all testers code, but not all of them started out as coders. But I'd like to understand first - what non-coding testing tasks have you got? Are you proposing that all tests will be automated now, or is it just that you feel you need more of the testers contributing to be able to build your automation suite?
    – testerab
    Jun 21, 2014 at 10:17
  • Thanks for all your comments, very apreciated. We explored BDD such as Cucumber and such. We cannot figured out how it could translate our complex steps into Java program using Webdriver. Our scrips will be more complex than "Given", "When", "Then" paradigm. I still apreciate Lyndon stategy to leverage. That's a pretty interresting approach. I also like Kate's approach to invole current programmers; those guys here are fantastic at their job, and we always work closely with them. Thanks all!
    – Brutalys
    Sep 16, 2014 at 17:39

3 Answers 3


I'd second Lyndon's additions to Dmitry's advice.

A few other thoughts from my experience:

  • a little formal logic never goes astray.
  • if any of your non-coders are strongly against learning to code, that's fine. You need strong manual testers too, and coding takes a mindset that not everyone possesses. The insight the manual people get from their introduction to automation will help them communicate with developers.
  • a big part of teaching someone to code, regardless of the purpose, is breaking down a large problem into smaller ones. Testers are already good at that, they just usually see the problem represented somewhat differently. Their problem is often "test feature X" and the breakdown is their test strategy, test plan, and test cases. Sometimes all you need is to demonstrate the parallels between coding and testing and your testers will be fine.
  • there will be a transition period. During that time, your group productivity will take a major hit. Don't push too hard - your non-coders are learning something new, and your coders are ramping up a relatively unfamiliar skill-set. The surest way to guarantee the failure of an initiative like this is to fail to adjust schedule for the transition period.
  • if at all possible, get your programmers involved. Having your programmers pairing with your non-coding testers to write automated tests will be valuable to both - the testers will have more insight into programming, and the programmers will have more idea of what the testers need to write good tests.

I'm going to completely agree with Dmitry, however, I'd like to add to it. This is a perfect example of when you could begin teaching your other testers to code.

I've seen this work very well with working sessions and paired programming. I've done this previously with a department where we got together every week or 2 for an hour and went over writing some test automation. About half the time was spent coding, and the other half answering questions. The goal was never to make them write test automation full time, but give them enough knowledge to help out, write some of their own scripts, and give them enough knowledge to know what types of questions they needed to ask. We would also typically give them "homework". We'd ask them to work on producing something very small and basic during any slower times they had by the time that we did the next session. Our management at the time was very open to giving people some time to do this to grow themselves. Even those who went on to never write another line of code ended up being able to communicate with our developers that much better.


As a possible solution:

You can add BDD solution to your test framework. For Java popular BDD solutions are JBehave and Cucumber-JVM. So other members will write tests in Gherkin human-like language.

How it looks like? — you may ask..

The test it self is a textual description:

Feature: Adding  

  Scenario: Add two numbers  
    Given the input "2+2"
    When the calculator is run
    Then the output should be "4"

Gherkin notation is used here which is:
Given [context] — When (I do) [action] — Then (I should see) outcome

Steps are implemented in programming language:

Given /^the input "([^"]*)"$/ do |input|
  @input = input

When /^the calculator is run$/ do
  @output = `ruby calc.rb #{@input}` raise('Command failed!') unless $?.success?

Then /^the output should be "([^"]*)"$/ do |expected_output|
  @output.should == expected_output

Often human-like stories are developed by manual testers
and then they're partially or fully automated by automation engineers.

  • You don't need to use any fancy tools to have BDD and human-like language. It will be enough to define clear DSL/API, embedded in your programming language + your IDE will help non-programming testers through autocomplete. Do Gherkin, JBehave or Cucumber have IDE support in autocomplete?
    – dzieciou
    Jun 20, 2014 at 20:45
  • 1
    Yes, they do have autocomplete IDE support. Jun 20, 2014 at 21:18

Your Answer

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

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