Selenium/Webdriver with team member that don't have programing skills

Question

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?

Thanks!

Answer 1

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.

Answer 2

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.

Answer 3

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
end

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

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

---

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