开发人员还应该充当测试人员吗？[关闭]

我们是一个由3个开发人员，1个设计师，1个Scrum管理员和1个产品所有者组成的Scrum团队。但是，我们的团队中没有官方测试人员。我们一直面临的问题是，测试应用程序并通过这些测试并消除错误已被视为考虑完成PBI（产品待办事项）的标准之一。

但是问题在于，无论我们（3位开发人员和1位设计师）尝试测试应用程序和已实现的用例的多少，仍然看不到一些错误，并且破坏了向利益相关者的展示（墨菲定律）。

作为补救措施，我们建议公司雇用新的测试人员。工作的人只能进行测试，并且只能进行测试。官方专业测试人员。

但是，问题在于，Scrum负责人和利益相关者认为开发人员（或设计师）也应该是测试人员。

对吗 我们开发人员（还是设计师）也应该成为测试人员吗？

事前：对于什么被视为非测试，似乎存在很多困惑。当然，每个开发人员都需要在创建代码时对其代码进行测试，并需要验证其是否有效。在他/她认为测试已经完成并且足够好之前，他/他无法将其交给测试人员。但是开发人员并没有看到一切。他们可能无法识别错误。这些错误只有在进行全面测试后才能在开发周期的后期发现。问题是开发人员是否应该进行这种测试，以我的拙见，这需要从项目经理的角度来考虑：

开发人员可以成为测试人员，但他们不应该成为测试人员。开发人员倾向于无意/无意识地避免以可能破坏应用程序的方式使用该应用程序。那是因为他们编写了它，并且主要以应使用的方式对其进行了测试。

另一方面，优秀的测试人员会尝试折磨该应用程序。他/她的主要意图是打破它。他们经常以开发人员无法想象的方式使用该应用程序。他们比开发人员更接近用户，并且通常使用不同的方法来测试工作流。

另外，使用开发人员作为测试人员会增加开发成本，并且与拥有专用测试人员一样，并不会为产品质量带来任何好处。当我可以用便宜的测试仪更好地完成作品时，我不会让开发人员进行交叉测试。仅当开发人员和测试人员之间的反馈循环变得过于昂贵时，我才会让开发人员对彼此的代码进行交叉测试，但是根据我的经验，这种情况很少发生，并且高度依赖于过程。

这并不意味着开发人员应该草率地将一切留给测试人员。在将软件交给测试人员之前，应通过单元测试来备份软件，并应将技术错误降至最低。不过，有时您可以在此处进行修复，解决在那里的问题或其他开发人员无法预见的错误，这没关系。另外，集成测试应主要由开发人员完成。测试人员的主要目的是验证是否满足要求。

在如此小的团队中（并且还取决于应用程序的大小），我还可以看到测试人员处于混合角色，编写单元测试和UI测试。你绝对应该雇用一个。

但是比测试仪更重要的是定期冻结/分支。不要提供任何未经适当测试的东西。添加功能或更改某些功能后，必须再次验证其周围的所有内容。如果您的公司没有声誉，您将只会获得不良声誉。不要释放不稳定的东西。当客户希望在某个日期之前拥有该软件时，请停止足够的早期开发并适当地测试它，以便您有足够的时间来修复错误。通常，拒绝最后一刻的功能请求总比没有很好地实施它们或在没有经过适当测试的情况下发布更好。

开发人员可以成为其他开发人员代码的测试人员。

但是测试您自己的代码并不是一个好办法-开发人员倾向于对自己的代码有心理障碍，因此难以设计全面或适当的测试。

总是会有开发者认为他们做得很好，但是通常他们做不到（而且我当然知道我有很多盲点）。

如果您真的不能聘请一名测试人员，那么让开发人员对彼此的工作进行交叉测试-也就是说，如果A编写了代码并进行了单元测试，则让B来检查那些单元测试并查看是否可以添加其他内容。并让B尝试（作为用户）测试代码并报告缺陷。

这不是完美的方法，但是比尝试做所有事情的单个开发人员要好。

有时，您的同事真的很擅长于破坏您的软件，因为他们会从中获得乐趣，并且不太在意-因为这不是他们的代码。

记者应该倾向于正确写作吗？我的意思是，查找所有语法错误是纠正者和编辑者的工作。

不过，记者可以自己进行一些拼写检查。尽管如此，校正器是一个独立且重要的职业。

对于开发人员和测试人员而言，情况相同，只是质量保证在开发中更为重要。即使您是一名优秀的开发人员，您也没有时间彻底测试所有测试用例，以涵盖产品所支持的所有环境，浏览器和操作系统。

如果一个人除了发展自己，而且还不断地做这项工作，那仅意味着一个简单的事实-他是兼职测试员。

无论我们（3位开发人员和1位设计师）尝试测试应用程序和实现用例的多少，仍然看不到一些错误，并且破坏了我们的演示文稿……给利益相关者。

考虑对一个或两个冲刺执行“受控运行”，分别跟踪开发和测试工作。在此运行结束时，分析收集的数据以找出您在测试上花费了多少精力。

如果您发现测试需要付出很大的努力，请将数据传递给管理层-这将是支持您请求的令人信服的证据（比现在更具吸引力）。

否则（如果您发现测试花费很少的时间），请考虑投入更多的精力以使其做得更好（或学习如何做）。与您的管理人员协商您计划进行的其他工作 -因为他们可能更愿意雇用测试人员。:)

...我们建议公司雇用新的测试人员。工作的人只能进行测试，并且只能进行测试。官方专业测试人员。

但是，问题在于，Scrum负责人和利益相关者认为开发人员（或设计师）也应该是测试人员。

必须承认，贵公司的管理层对我而言相当la脚。我的意思是-好吧，这可能是真的很难找出许多如何测试将是最适合的项目，细腻。

但是至少要有一个测试员只是一个安全的赌注-真是可笑，他们在声称自己敏捷 / 敏捷的同时，不惜尝试一下。

好吧，在第一个开发人员对输入屏幕进行了一些更改之后，我们有两个开发人员进行了交叉测试。那是我们的常规测试员休产假的时候。

他基本上改变了“发票清单”屏幕，用户在放大之前通过“编辑”按钮进行了一些编辑，这些屏幕通常用于选择发票。原来的列表被扔掉了，并插入了一个新的gridview，它具有过滤，分组，排序和各种很酷的功能。

测试进行得非常好，他们第二天将更改上传给客户。两周后，客户打电话说：“我们真的很喜欢您输入的新东西，现在我们可以看到各种信息。但是……呃……现在我们要去哪里编辑发票？ ??”

原来，开发人员拿出了复选框（用于选择）和“编辑”按钮，并且由于开发人员始终总是双击以选择一个项目，所以他们都没有发现任何问题……

开发人员和用户生活在不同的世界中，进行交叉测试比使开发人员测试自己的工作要好，但是仍然不尽相同。

正如这里的其他人所说，开发人员可以交叉测试彼此的代码（单元或功能测试），也许您的Scrum管理员和产品所有者可以帮助进行集成测试，但是对于用户接受度测试，您应该确保获得来自客户测试的大量反馈 -这意味着他们可以按照真实用户的方式进行频繁部署，并拥有真正开放的通信渠道。

您应该在设计时考虑到可测试性，但是如果您没有专用的测试人员，那么某些事情将简单地溜走，因为一天中没有足够的时间来设计，实施和测试软件。

测试软件是专职的工作。要成为一名优秀的测试人员，需要有良好的头脑，才能和丰富的经验。认为软件开发人员无论多么聪明，都可以在测试只是他日常工作的一小部分时接近专业测试人员，这是荒谬的。

除此之外，还有一个问题，即软件开发人员在潜意识里不想发现错误。

我同意他们的观点，即开发人员/设计人员应该测试他们的代码，并声明做过一段代码的设计人员/开发人员不是致力于付诸实践之前对该代码的唯一“视线”。尽管这并不能解决所有问题，但这至少有助于避免在开发过程中测试和重新测试自己的代码时出现的盲目性。

从用例的提及中，我将假定您也在使用代码覆盖率工具？如果没有，它可能有助于查看哪些代码可能未经测试，并且在某些情况下可能会弹出意想不到的错误。

话虽如此，如果有足够的工作或您的组织规模合适，我同意需要一个专业的质量检查人员，这将有助于使每个人的角色更加集中，他们还可以查看是否存在任何模式被错过了，更重要的是，如何解决它。