你用什么方法来测试-感染你的工程师？

Question

让我以引用JUnit测试感染:程序员喜欢写作测试的一段话的形式开始一些上下文：

每个程序员都知道他们应该为他们的代码编写测试。很少有人会这么做。对“为什么不？”的普遍反应？就是“我太急了”这很快就变成了一个恶性循环--你感觉到的压力越大，你编写的测试就越少。编写的测试越少，效率就越低，代码就越不稳定。你的工作效率和准确性越低，你的压力就越大。

我是三个(五个开发人员大小) Scrum团队的测试工程师。我不能做他们所有的测试工作。因此，我正在训练他们成为更好的测试人员，并不断改进他们的过程。

我坚信，做一个好的软件开发人员的一部分就是做一个好的测试人员。-- 约翰·索梅兹

这就引出了我的问题：

您用什么方法使工程师(无论是测试人员还是开发人员) 试验感染 (或TestHappy)?

我在寻找我从未尝试过的方法。每个答案最好有一种方法，除非它们不能被单独使用。(通过这种方式，我们可以投票给我们认为是最好或最有希望尝试的方法，当然，对于大型团队中的单个测试人员来说也是如此。)

Answer 1

在厕所上的测试(来自谷歌)

在厕所上重复在厕所上测试打印可能是一种传播测试知识和让开发人员进行更多更好测试的方法。

我已经下载了所有的谷歌ToT文章到一个文件夹，你可以找到他们在这里。这样你就不用浏览整个博客了。

每个厕所打印一个，工程师们每周打印一次。我从测试行为未实现开始。

研究结果如下：

• 反应是积极的

Answer 2

挑战开发者

另一家我为之工作的公司举办了开发人员/测试人员之间的竞赛。人们喜欢挑战；当被要求尽快提出新的测试想法和编写测试时，他们变得非常有动力。

结果：

• 几个小时内，除了编写测试用例之外，还出现了许多新的想法。
• 你得在个人层面上更好地了解你的同龄人。

Answer 3

使它变得容易

• 构建框架，以屏蔽和排除系统的部分内容
• 树立榜样
• 允许重用用于集成测试的使用框架(BDD框架在这里工作得很好)

使开发人员

受益

• 使用新技术
• 把它当作一个研发项目
• 允许开发人员使用测试类作为扩展技能的区域。

让它变得有趣

• 挑战
• 举行小组会议/知识转让

解释福利

防止：

• 晚上打电话
• 循环
• 未定义的代码段
• 作出改变的不明确后果
• 困难重构
• 低码质量
• 对需求的理解不足

使团队能够拒绝不明确的需求

可能是最重要的部分，确保团队有能力拒绝需求或创建一个研究任务来定义需求。如果在计划期间，团队无法为需求定义大多数基本测试，那么它们是不明确的。通过让团队对测试更加热情，它将使他们能够预先定义测试并了解需要进行哪些更改。如果它们无法定义测试，则应该重新定义需求，以使其更加清晰。