公司外包测试；我们如何鼓励程序员停止过度依赖测试人员？

Question

我的一个朋友在一家200人的公司工作.该公司的业务与IT无关，但他们确实有一个IT部门，除其他外，在他们的网站上，客户使用。

该网站一开始就有一个核心理念，即程序员必须使用自动化测试来测试应用程序。然而，它很快就成了问题，因为程序员花了太多的时间用硒 (以及后来的Cypress.io)编写功能测试，试图处理复杂的交互，比如拖放或文件上传，或者试图找出为什么测试会随机失败。有一段时间，超过25%的时间花在了这些测试上；而且，大多数程序员对这些测试感到愤怒，因为他们想要产生实际价值，而不是试图弄清楚为什么这些测试会随机失败。

两年前，一家来自保加利亚的公司决定由一家公司手工进行功能、界面级测试。事情进行得很顺利，因为这样的测试非常便宜。总的来说，程序员提供功能的速度更快，回归也更少，每个人都很高兴。

然而，随着时间的推移，程序员开始变得过于自信。他们会编写更少的集成，甚至是单元测试，有时会在没有实际检查的情况下标记特性，如果它们在浏览器中工作:既然测试人员会发现错误，为什么还要麻烦呢？这就产生了两个问题：(1)当测试人员几天前发现问题时(与程序员自己在几分钟内发现的问题相比)，解决这些问题需要更多的时间；(2)外包测试人员的总成本不断增加。

最近，团队领导试图通过以下方式来改变这种行为：

• 衡量每个人有多少张票被测试人员重新打开(并将结果分享给整个团队)。
• 向表现最好的人表示祝贺，也就是那些门票最少的人被重新开放。
• 花时间和那些表现最差的人一起编程，试图理解为什么他们不愿意测试他们的代码，并向他们展示这并不是那么困难。
• 解释说现在解决一个问题要比等待几天来测试这个特性要快得多。
• 说明测试人员只进行系统测试，而缺乏单元测试使得很难确定问题的确切位置。

但是，它不起作用：

• 这些指标并不总是相关的。一个人可能工作在一个不清楚或复杂的票，被测试人员多次重新打开，因为边缘的情况，同时，一个同事可能工作的票是如此直截了当，根本没有机会引入任何倒退。
• 程序员不愿意测试代码，因为(1)他们觉得代码很无聊，而且(2)如果他们不测试代码，他们似乎更快地交付了这个特性。
• 他们也不明白为什么在开发一个特性几天后修复一个问题会成为一个问题。他们理解这个理论，但在实践中却没有感觉到。此外，他们认为，即使要花更长的时间，公司支付廉价外包测试人员的费用仍然比程序员花在测试上的时间更便宜。一再告诉他们，情况并非如此，没有任何效果。
• 至于系统测试还是单元测试，程序员回答说，他们不会花那么多时间来查找测试人员报告的问题的确切位置(这似乎是真的)。

还能做些什么来鼓励程序员停止过度依赖测试人员？

Answer 1

在我看来，这里的政策是矛盾的。

一方面，该公司外包了测试，因为它占用了程序员过多的时间，而且其他人可以更便宜地完成测试。

现在，他们抱怨程序员依赖于测试人员，应该提前做更多的测试。

我可以从管理的角度理解，人们认为这是一种快乐的媒介，但实际上程序员并不是在逐个案例的基础上对他们自己做了多少测试和外包了多少测试进行了密切的分析。

尝试这样做会花费太多的时间和智力努力，而且很可能不会产生准确的结果。程序员将如何估算一段特定代码有多少bug，然后权衡花费自己的时间搜索它们与让测试人员搜索它们的经济效益？这太荒谬了。

相反，程序员遵循的是经验法则。以前的规则是进行广泛的测试。现在的规则是节省宝贵的程序员时间，让更多的代码走出家门，把测试留给测试人员(他们被认为是一便士)。

寻求一个快乐的媒介是没有答案的，因为在实践中，肛门保留者将恢复25%的时间测试，而牛仔们将继续把低质量的代码抛出门外，而责任心和对细节的关注(或缺乏细节)等个性特征将主导判断。如果管理层试图对这两种人进行骚扰，让他们更接近经济上理想的平均水平，那么这两种人可能最终都会感到受到骚扰。

我亦想顺便说一句，刚开始测试的时间，有25%，我觉得并不过分。

Answer 2

好吧，我们都有着保护和保护开发者的共同目标，但是你的问题中有些事情让我有些不舒服……

他们也不明白为什么在开发一个特性几天后修复一个问题会成为一个问题。他们理解这个理论，但在实践中却没有感觉到。

我很抱歉告诉你这个消息，但是有经验的程序员确实觉得在实践中尽早发现错误是有价值的。

至于系统测试还是单元测试，程序员回答说，他们不会花那么多时间来查找测试人员报告的问题的确切位置(这似乎是真的)。

这是教科书上的防御性言论(闻起来有些被动--咄咄逼人)。当然，这是true....until，你把它放在正确的角度。你可以问程序员..。他们在浏览器中使用书签吗？他们的主页是搜索引擎吗？他们是否使用alt+tab在应用程序/窗口之间切换？所有这些都是生产率提高的可怜借口.如果你做过一次。当你一直这样做的时候，这几秒钟很容易就能总结出无数的人--有效率的日子。您的程序员那是他们感觉到的时间。实际时间包括测试人员的时间、准备报告/归档票据的时间、通信详细信息可能花费的时间以及关闭已解决的票据/报告的时间。时间就是金钱，对吧？

想一想，当你去买食物时，忘了买牛奶。你在店里的时候步行一分钟就到了。当你在家的时候，它是成倍增长的。现在，从长远的角度来看，这就是1分钟的感觉时间对所有参与者来说是如何转化为30分钟的实际麻烦的(尽管在现实中它可能要多得多)。如果管理层知道，在目前的情况下，适当的测试可以为公司节省大约30倍的时间，他们会有什么感觉？

而且..。

有一段时间，超过25%的时间花在了这些测试上；而且，大多数程序员对这些测试感到愤怒，因为他们想要产生实际价值，而不是试图弄清楚为什么测试会随机失败。

再次，我很抱歉地告诉您这个消息，但是有经验的程序员知道，测试的实际价值加上25%的时间实际上并不是那么糟糕的百分比。好的测试是值得他们的长度黄金！此外，测试不会随机失败，至少不会像你想象的那样经常失败。至少不是好的测试，所以测试的质量也是必须认真考虑的一件事。例如，想想CE标记，这一切都是关于测试的！程序员是否同样不同意它确实增加了产品的实际价值？

然而，上一次引用OP声明的实际问题在于，它似乎暗示，管理层实际上已经接受了程序员的建议，将测试外包出去，或者至少受到了程序员厌恶测试的影响，而其他答案可能表明，管理层本身就把这一切搞砸了。

程序员不愿意测试代码，因为(1)他们觉得代码很无聊，而且(2)如果他们不测试代码，他们似乎更快地交付了这个特性。

管理层偶尔会搞砸，对吧？似乎压力已经建立在快速交付功能上，这已经渗透到了整个文化之中。不幸的是，在过分的压力下，偷工减料和跌落测试是手牵手的.

经验丰富的程序员会在测试是否值得花时间的问题上大做文章，而不是像他们说的那样，抱怨他们浪费了时间，也没能交付价值。我的主张是，必须给出一个简单的解释，即程序员相对缺乏经验，但同时，他们正在处理的整个系统也没有那么复杂，所以他们还没有遇到太多的麻烦，才能真正感受到正确的自动化测试的价值。

在这里，我只能给出一个建议，那就是让开发人员不惜一切代价地感受到测试的实际价值。同时，保持外部测试人员，并尽可能地编写适当的自动化测试。如果输出不太复杂，安全，等等.公司可能没有外部测试人员，但这始终取决于细节。

Answer 3

不要仅仅假设您对集成测试的过度依赖是正确的。你在追求错误的东西。在驱使人们取得可衡量的结果和实际的结果时要非常小心。

衡量每个人有多少张票被测试人员重新打开(并将结果分享给整个团队)。

对不起，这太蠢了。当代码掌握在测试人员手中时，程序员的工作就不会完成。计算代码与程序之间来回的次数是适得其反的。你想让程序员和测试人员打交道。不要因为他们这么做而惩罚他们。优秀的程序员为他们的测试人员欢呼。他们不会躲着他们。

向表现最好的人表示祝贺，也就是那些门票最少的人被重新开放。

这不是最好的衡量标准。你是在奖励那些能隐藏他们的错误的人，而不是那些努力让他们被消灭的人。

花时间和那些表现最差的人一起编程，试图理解为什么他们不愿意测试他们的代码，并向他们展示这并不是那么困难。

每个运行他们的代码的人都在测试他们的代码。当人们不明白自己是如何被评判时，聪明的人甚至都不会去猜测。他们只是很快地接受了判断，并希望从结果中学到一些有用的东西。我们对这种行为有一个很好的说法。这叫做敏捷。

现在，请不要认为这意味着我不喜欢对编程。我爱死它了。我学到了更多，坐下来和其他程序员一起讨论一个问题，然后从任何一本书或博客中学到更多。等不及这个贪欲的东西消失了，这样我就能把它弄回来。

但如果你所做的只是说教，那就不是对对编程了。如果你这样做了，闭嘴，听你的搭档说。你可能会学到一些东西，却发现你的问题不是你想的那样。

解释说现在解决一个问题要比等待几天来测试这个特性要快得多。

这是你的问题。测试一个特性不需要几天的时间。想想像水泥一样的代码。它坐得越久，移动起来就越困难。给我更快的测试反馈。最好在我开始考虑其他功能之前。

捕获错误所需的时间越长，修复的成本就越高。

说明测试人员只进行系统测试，而缺乏单元测试使得很难确定问题的确切位置。

停止解释并进行对等单元测试。它让他们知道你想要什么。程序员用代码进行最好的沟通。这样他们就可以这么做了。

工作方式如下:我编写了一个单元测试。我编写通过单元测试的生产代码。您可以对代码进行同行检查，注意到一些不正常的地方，然后编写一个单元测试，证明它是错误的。您将单元测试发送给我，我查看它，或者通过它，或者我们讨论真正的需求应该是什么。进行对等单元测试，您的弱单元测试人员将从您的强单元测试中学习。奇怪的是，强者也会向弱者学习。

哦，当你对程序的时候，你可以做到这一点。让整件事进展得很快。

说到需求，如果集成测试人员不是关于需求的讨论的一部分，以及哪些需求是可测试的，那么在这个编码开始之前，您就疯了。他们发出了需求是可测试的集成调用。程序员在开始设计之前就应该知道这是怎么回事。

在通过同行评审和对等测试之后，您将代码发送给集成测试人员。现在，两位编码人员很早就发现了这一点，他们都应该支持测试人员找到任何剩余的bug。他们不应该试图把他们藏起来。他们应该公开报告任何可能帮助集成测试人员找到他们的事情。

不是程序员和测试人员。我们都是为了对付虫子。

因此，不要再奖励那些创建不可测试代码的人了。