Selenium / Webdriver和没有编程技能的团队成员

#1 楼

我将林登（Dynry）的建议列为第二建议。

根据我的经验，还有其他一些想法：


一点点形式逻辑永远不会误入歧途。
如果您的任何非编码人员都强烈反对学习编码，那很好。您还需要强大的手动测试人员，并且编码需要一种并非所有人都拥有的思维方式。手动人员从自动化入门中获得的见识将帮助他们与开发人员进行交流。
无论出于什么目的，教别人进行编码的很大一部分将一个大问题分解为更小的问题。测试人员已经很擅长这一点，他们通常只是看到问题代表有所不同。他们的问题通常是“测试功能X”，而细分是他们的测试策略，测试计划和测试用例。有时，您只需要证明编码和测试之间的相似性，您的测试人员就可以了。
会有一个过渡期。在此期间，您的团队工作效率将受到重大影响。不要太用力-您的非编码人员正在学习新知识，编码人员正在提高相对不熟悉的技能。确保这样的计划失败的最可靠方法是不调整过渡期的时间表。
如果可能的话，请让您的程序员参与进来。让您的程序员与您的非编码测试人员配对以编写自动化测试对双方都很有价值-测试人员将对编程有更深入的了解，并且程序员将对测试人员编写好的测试所需的内容有更多的了解。

#2 楼

我将完全同意Dmitry，但是，我想补充一点。这是一个很好的例子，说明您何时可以开始教其他测试人员进行编码。

我已经在工作会议和配对编程中看到了很好的效果。之前，我曾在一个部门完成此工作，我们每周或每2个小时聚会一个小时，然后完成一些自动化测试。大约一半的时间花在编码上，另一半用于回答问题。目标绝不是让他们全职编写测试自动化程序，而是要给他们足够的知识来提供帮助，编写自己的一些脚本，并给他们足够的知识来知道他们需要提出什么类型的问题。我们通常还会给他们“作业”。我们要求他们在下届会议之前的任何较慢时间内，制作很小而基本的东西。当时我们的管理层非常乐于给人们一些时间来发展自己。即使是那些从不编写其他代码的人，最终也能够更好地与我们的开发人员进行通信。

#3 楼

可能的解决方案：
您可以将BDD解决方案添加到您的测试框架。对于Java，流行的BDD解决方案是JBehave和Cucumber-JVM。因此其他成员将使用类似Gherkin的人类语言编写测试。

看起来如何？ —您可能会问..
自我测试是一个文本描述：

Feature: Adding  

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

此处使用小黄瓜表示法：给定[上下文] —何时（我愿意） [动作] —然后（我应该看到）结果


步骤是用编程语言实现的：

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

通常是人为的-类似的故事是由手动测试人员开发的，然后由自动化工程师将其部分或完全自动化。