没有“专用”测试人员角色的开发团队的生存能力

最近我一直在思考如何建立精益开发团队。最终，我想与少数志同道合的人一起开设自己的小软件商店。目标不是致富，而是拥有一个健康的工作环境。

到目前为止，我将精益团队定义为：

• 小;
• 自组织；
• 所有成员都必须牢记质量保证；
• 成员必须能够执行多个角色

最后一点是我有点担心，因为随着口头禅的发展……

开发人员会成为糟糕的测试人员。

虽然我知道开发人员通常与他们的代码或同事的代码“过于接近”，无法对质量进行更高级别的评估，但我并不认为他们实际上是糟糕的测试人员。相反，我认为优秀的开发人员的素质与优秀的测试人员的素质有很大的重叠。

假设这是正确的，我一直在思考解决开发人员/测试人员问题的不同方法，我相信我已经提出了一个可行的模型。

我的模型要求：

• 一个带有2个以上项目的小型软件公司
• 开发和交付的敏捷（迭代）方法
• 每个项目1个团队
• 所有团队成员均为软件开发人员
  • 他们的工作描述将清楚地说明开发，质量保证，测试和交付为职责

如果满足所有这些先决条件，那么可以按以下方式组织项目（此示例将引用两个项目A和B）：

• 每个团队成员将在开发人员角色和测试人员角色之间交替
• 如果团队成员是项目A的开发人员，那么他们将是项目B的测试人员
  • 会员将在时间上只有1个项目上工作，因此预计将充当无论是一个开发或测试员。
• 甲角色周期由3次迭代作为开发和2次迭代作为测试仪（再次，在两个不同的项目）
• 项目团队将始终具有3个开发人员和2个测试人员。
• 成员角色周期应相差1次迭代。
  • 这样可以最大程度地减少团队变更的突然性。对于每个迭代，2个Devs和1个Tester将与上一个迭代相同。

鉴于以上所述，我看到以下优点和缺点：

优点

• 在整个公司范围内分配项目知识。
• 确保团队成员没有测试他们帮助编写的代码。
• 角色周期异相意味着没有项目拥有100％的成员切换。
• 交替角色打破了无聊项目的单调性。

缺点

• 两个项目的迭代紧密耦合。如果一个项目要在中途取消迭代并重新开始，则这两个项目将不同步。这将使角色周期难以管理。
• 聘请开发人员的铰链也开始充当测试人员的角色。

与朋友和同事讨论这种方法时，我收到了好坏参半的评价。有些人认为很少有开发人员会愿意像这样的角色，而另一些人则告诉我，他们个人愿意尝试。

所以我的问题是： 这样的模型可以在实践中起作用吗？如果没有，是否可以将其调整为可行的模型？

注意： 为了简洁起见，我仅关注Dev和Tester角色。如果需要，我将继续介绍其他角色。

我不同意

开发人员成为不良测试人员

在我的职业生涯中，大多数团队都没有任何QA支持。其中包括一些大型的全球性公司，涉及诸如其全球登录和注册系统之类的产品。在另一种情况下，我有30％的公司收入来自办公桌上的一个盒子。（顺便说一句，这些做法不建议使用；））这些公司依靠工程师来确保其代码正确运行。而且，我们注重细节，有点强迫并且为我们的工作感到自豪，因此将竭尽全力确保我们的软件正常工作。

此外，作为一个开发者，我做很多超过测试仪测试。我通常对代码进行90％的单元测试，如果不使用Java，则要进行100％的单元测试。

我喜欢与测试人员一起工作，因为他们确实从不同的角度来看待它，并且抓住了我没有想到的东西。但是我真的不希望它们提供超过30％到50％的测试覆盖率，而我自己对100％负责。（顺便说一句，这并不是对他们的抨击-它们通常散布在各个项目中。）

与其问工程师是否要进行质量检查，不如问他们：是否在生产中出现错误，由谁负责？如果我引入了错误，并且客户遇到了错误，我会感到难过并承担责任。我不怪QA伙计们。恕我直言，这就是您要雇用（和与之合作）的工程师

我确保质量的方法是：a）超级进取的单元测试（尽管我不能完全自己进行完整的测试驱动开发），b）强大的代码审查过程确实有帮助，并且c）整合了不耐烦和不耐烦缺陷融入团队文化。

总是让我感到震惊的是，最高级的人是最勤奋，最细心的人，因为他们可能会指出更大的问题。但主要是他们是最愿意花时间把事情做好的人。

但是我工作过的大多数团队，特别是对小型公司而言，都没有正式的质量检查组件。

我同意@Rob Y的回答，并想补充几点：

• 在敏捷中，团队中专用的测试人员是一种反模式，因为他们迫使团队进行工作流水线并且固有地效率低下。您总是以“开发完成”但未经测试的故事结束。如果专用测试人员在团队（或独立团队）之外工作，则很好。

• 开发人员会造成不良测试人员...而测试人员会造成不良测试人员。质量检查很难。实际上，这很难。您的问题可能不在于人员和角色。您的问题可能是您的软件被赶出了。同样，在敏捷中，您的团队有责任在生产前进行测试（无论他们是否有专门的质量保证）。

• 质量保证是开发的一部分，例如重构，体系结构等。开发团队的责任是按照一定的，约定的，切合实际的标准来生产软件。质量保证不会提高该标准。更好的开发人员可能会。

• 挑衅：谁说质量保证胜过质量检查开发人员？这是人们说的话，但是... [需要引用]。质量保证所需的“黑客”心态是开发人员心态。实际上，基本上所有的黑客都是开发人员，或者是开发人员，而不是质量检查人员。

• 挑衅2：99％的质量检查工作可以（并且我敢说应该）通过脚本自动化。一个好的团队会做到这一点，而要正确做到这一点，您需要...开发人员。

在上一份工作中，我们只有开发人员，而没有质量检查人员。结果，如果一个问题一直困扰到生产，就没有其他人要怪了。我们非常重视质量检查责任，并高度依赖自动化测试套件。由于编写自动化测试仍在编写代码，因此让开发人员执行该任务并不重要。

关键是使它成为团队文化的一部分，也是每个项目的一部分。我们制定了测试计划（只是我们打算为项目编写的测试的简短列表），其他开发人员将审查并建议我们遗漏的案例和方案。

如果您对此严格，它可以很好地工作。它为我们做到了-我们始终在线的电子商务Web服务的正常运行时间长且缺陷少。

首先要注意的是-我曾经担任过QA工程师和软件工程师的专业工作。

这样的模型在实践中行得通吗？

一切皆有可能。

虽然我知道开发人员通常与他们的代码或同事的代码“过于接近”，无法对质量进行更高级别的评估，但我并不认为他们实际上是糟糕的测试人员。相反，我认为优秀的开发人员的素质与优秀的测试人员的素质有很大的重叠。

这取决于您需要哪种测试。如果您需要麻木的，单调的，重复性的手动测试，以确保每个屏幕或元素都已真正翻译成Elbonian，那么您将遇到问题。

以我的经验，每个项目至少都需要进行此类测试（即使不是每个项目都进行了这种测试）。问题是您不会从不熟悉质量检查最佳做法的人员那里得到这种测试。地狱，您甚至没有从了解最佳实践的人那里得到它，而是“信任”开发人员。

作为测试人员，您不能信任开发人员。我忘了发现的错误“可能不是由该更改引起的”或“在我的开发箱中工作得很好”的错误。

即使您能找到能够容忍不做自己喜欢做的​​事情的开发人员（五分之二），您也会遇到这个核心矛盾。更糟糕的是，您正在花费时间和精力来训练人们擅长两项工作，而不是一项。公司有足够的时间来寻找和培训擅长一项工作的人，更不用说两项。

也许您在某种程度上很棒，但我还没有遇到过-但我对此表示怀疑。

我认为它可以工作，但是有几件事我可以确保您做得到。

1. 对候选人的双重角色要非常提前。由于多种原因，它并不适合所有人。如果您有太多不喜欢它的人，那您就会失败和流失。
2. 有一个计划，您可以在其中评估将其纳入团队的最佳方法。尽管我想一次只专注于一个任务/项目，但是我不确定我是否不想长时间编程。也许测试是远离编程的美好假期。并非仅是简单一些，只需使用一些不同的脑细胞进行更改即可。在决定最好的方法之前，请准备好以不同的方式尝试它。

同步项目似乎不是一个可行的解决方案。如果某人是项目的测试人员，那么他们可能是替代程序员的最佳人选，反之亦然。

这个计划不能使团队自我组织足够。一种策略可能并不适合所有团队和所有项目。