问你在离岸或外包测试方面的经验是什么？

EN

当然，你可以雇佣那些不懂测试的人来完成测试，但我希望它和雇佣那些对编程一无所知的人来做你的开发一样成功。

测试服务基本上只是由专业软件测试人员组成的咨询服务。

测试是一种具备所有相关知识、最佳实践等的技能。具有经验的专业系统测试人员通常是具有正确测试能力的人，他们花了多年的时间了解自己在做什么。对于一个随机的个体来说，情况就不是这样了。

一个好的测试人员将知道如何根据所提供的需求开发测试策略、试验计划和测试脚本。他们知道如何准确地评估测试覆盖范围和进度，他们将了解如何和何时执行回归试验，并了解为什么测试必须是可重复的，并且可以以允许开发人员轻松再现它们的方式记录缺陷，他们知道什么时候没有时间测试所有东西(几乎总是如此)，如何以最有可能保持质量的方式平衡各种压力(例如条带化)。

Ranty位

当人们贬低他们所拥有的技能并认为这是很容易学到的时候，开发人员就会很生气，但对我来说，这是一回事。当程序员提出这样的问题时，他们对其他专业人员所做或知道的事情几乎没有考虑，他们有什么权利期望其他人在技能方面有不同的表现？

说真的，对什么是真正的测试以及所涉及的问题做一些研究。

Ranty位结束

就离岸测试的具体细节而言，它与离岸测试有许多相同的问题，很大程度上是由两方面引起的:沟通和文化设置。

沟通是显而易见的。我只想说你需要一个策略来处理它，而主要的问题应该是“当开发者说他们看不到错误时，测试人员将如何向他们展示bug，而在他们的办公桌上游走不是一种选择？”任何涉及电子邮件或其他文字描述的问题的答案都应立即与之联系。

文化设置很少被谈论，但对我来说是一个更重要的因素。文化我不是指种族，我指的是商业文化。我工作过的大多数公司都没有针对数百英里外的团队成员的业务流程。他们编写的规范不够详细，不需要询问编写规范的人(现在处于不同的时区)就可以从他们那里工作。他们的运作假设，快速会议，以充实的东西，是丢失或不清楚的是容易组织的。

这就是我想要看到的--你的流程是否真的很好，可以和那些不能轻易来问问题的人一起工作?如果他们不是，你能改变他们，这样他们才能工作(而且你想要这样做)。

让公司以外的人对你的软件进行测试的问题是，他们对你的软件一无所知。因此，您需要确保您有良好的文档，以便他们能够测试系统:例如，需求规范、测试规范、用户指南等。

他们也不会关心你的软件。因此，您需要有一个体面的合同到位，以确保系统是经过测试的属性。

更重要的是，您需要与测试人员保持良好的关系，因为您和您的开发人员将经常与他们打交道。

理想情况下，随着系统的开发，他们需要参与进来。事情变了，规格变了。他们可以在这里作出公正和非常有用的贡献。

从个人经验来看，外包测试可能比它的价值要麻烦得多。测试、发现和修复bug之间的周转时间可能很长--不是几个小时，而是几天。在项目的关键时刻--即系统测试！--您可能不想与公司以外的人打交道，在另一个时区和文化中。

在你需要处理的问题上，已经有了一些很好的答案--所以我将把重点放在这部分：“你能不能用一个测试脚本雇佣一些离岸的‘机械土耳其人’...，作为专业软件测试服务的一个更便宜的替代方案？”具体来说，使用测试脚本代替经验的想法。我强烈建议你不要为了“只运行”你所写的测试脚本而在一家外部公司招聘。

这是一个常见的误解，通常在标准学校中最流行，您可以通过获得一个测试引导来编写真正详细的测试脚本，从而使廉价的未经训练的测试猴子忠实地遵循测试脚本，从而从本质上将“硬部分”分开。这不仅是为了让一位架构师编写非常详细的指令，让一群廉价的未经训练的代码猴子忠实地遵循--也就是说，并不是很好，但非技术经理喜欢看到它，因为看起来正在进行大量的工作。

我观察不熟练的测试人员遵循脚本的经验是痛苦的。当人们专注于脚本执行的时候，他们确实会忽略那些最明显的错误。然而，这不仅仅是一个未经训练的问题--详细的过程测试脚本是众所周知，这是一种无效的测试方法。当技术熟练的测试人员专注于测试脚本时，他们也会克服缺陷--许多测试人员之所以仍然有效地使用这种方法，是因为他们没有遵循脚本，他们只是将它们作为一个粗略的指南--我知道，我知道，因为在大量脚本的环境中工作多年，这就是我所观察到的。(然而，如果你直接挑战他们，大多数人会否认这一点，因为他们相信他们会和他们的经理们陷入麻烦。在某些情况下有正当理由)。

简而言之:脚本不会以缺乏技能或缺乏产品知识来解决问题。