您认为软件工程师必须担任一段时间的质量保证工程师是一个好主意吗？[关闭]

我相信是。为什么？

1. 我遇到了许多软件工程师，他们认为它们在某种程度上优于QA工程师。我认为，如果他们在一段时间内担任质量检查工程师的工作，并且意识到这是一种独特而有价值的技能，可能会有助于打破这种信念。

2. 软件工程师测试自己的程序的能力越强，在整个软件开发生命周期中进行代码时所花费的时间成本就越少。

3. 软件工程师花更多的时间思考程序如何崩溃，他们在开发它们时会更多地考虑这些情况，从而减少最终产品中的错误。

4. 软件工程师对“完整”的定义总是很有趣的……如果他们花时间担任质量检查工程师，那么这个定义可能会与软件设计者更加接近。

请注意，我在上面的建议中只考虑了很小的时间范围，因为我知道有人在某个职位上工作而不是被雇用，这绝对是失去该开发人员的秘诀。

你们怎么想

1.我遇到了许多软件工程师，他们认为他们在某种程度上优于QA工程师。我认为，如果他们在一段时间内担任质量检查工程师的工作，并且意识到这是一种独特而有价值的技能，可能会有助于打破这种信念。

优秀的软件工程具有质量背景，包括测试，指标和统计信息。任何进行任何类型的软件开发的人都应该知道（如果不熟悉）以高质量的源代码维护和产生/维护有效的测试用例。随着时间的流逝，我怀疑任何软件开发人员都会对质量的不同方面有所了解-代码质量，可移植性，可维护性，可测试性，可用性，可靠性，效率和安全性。

软件工程师可能会专注于生命周期的特定方面-需求工程，架构和设计，构造，测试和维护。但是，无论您关注什么重点（无论是工作还是项目的当前阶段），记住质量都是很重要的。

2.软件工程师测试自己的程序的能力越强，在整个软件开发生命周期中进行代码时所花费的时间成本就越少。

可能是真的。但是某些问题最好在以后的开发中看到。例如，在集成之前可能看不到性能和效率问题。拥有良好，可靠的代码和有效的单元测试只是开始。质量需要从需求开始，并一直贯穿于维护活动。

3.软件工程师花更多的时间思考程序如何崩溃，他们在开发它们时会更多地考虑这些情况，从而减少最终产品中的错误。

这是完全正确的说法。但是话又说回来，由需求工程师来验证需求中是否没有冲突，由架构师确保设计确实满足需求，依此类推。每个人都应该尝试戳破他们的工作中的漏洞，然后与适当的人一起工作，以使他们紧密而紧密地联系在一起。

4.软件工程师对“完整”的定义总是很有趣的……如果他们花时间担任质量检查工程师，那么这个定义可能会更接近软件设计者的需求。

“完全”只能根据要求进行度量。满足要求并完成了项目，或者存在不完整的要求而未完成的项目。任何其他完整的衡量标准都是没有用的。

使程序员对其代码负责并要求他们修复自己的错误可以解决此问题。那和失去奖金和/或工作。

并不是说这种经验无济于事，但是您采用这种思路能走多远？技术支持，销售，Beta用户请擦洗马桶（这将是一次令人沮丧的体验）。

“ ...必须担任质量检查工程师...”？您听起来像是对抗性的或惩罚性的。

我是软件开发人员。即使我们拥有质量检查部门，我也认为自己也要成为质量检查工程师是我工作的一部分。我的工作是交付能够完成某些任务的软件，为此，我必须编写单元测试并确保软件通过测试。

我与我们的质量检查部门合作。我的目标是使他们的工作更轻松，就像他们的工作是帮助我实现我的目标，即交付能够完成应有的功能的软件，从而使我的生活更轻松。正如我进行单元测试一样，我认为它们是我的第二只眼睛，有点像安全网。

我选择开发软件，并且想要开发软件。如果某个经理来找我，并告诉我我无法做到这一点而必须进行质量检查，我会告诉他们他们需要找到新的软件开发人员和质量检查人员，因为我不会在那儿工作。我和我的代码一样，但是我的创作过程和编程难题/挑战对我来说非常重要。如果我不能编写代码，我宁愿回到驾驶叉车，因为在公司环境中没有创造力和挑战自己的方式对我来说绝对是地狱。

总的来说，您提供的选项听起来很具对抗性，让我想知道您是否与一些糟糕的开发人员有过真正的糟糕经历。在我看来，开发人员必须始终意识到质量问题和测试，并且应该为自己的工作感到骄傲，直到他们通过了单元测试中的严格测试（如官方质量检查部门所使用的那样），他们才认为它没有完成。如果我有一个同龄人，或者是团队的技术负责人，并且有一位开发人员对质量检查表示“满意”，那么他会发现我将他拖出以纠正态度。如果软件交付硬币的双方不能合作并不能作为一个团队，那么就存在一个真正的文化问题。我不想在那里工作，人力资源以及高层管理人员都需要加入。

让程序员担任质量检查工程师的工作是失去最佳开发人员的秘诀。编程和质量检查需要不同的技能和思考过程。

但是，重要的是，您的程序员必须熟练掌握测试和验证自己的工作，然后再将其传递给质量检查团队。开发人员和质量检查人员可以使用不同的工具，知识和技能。开发人员需要熟练地逐步执行代码以查找意外行为，对边界条件进行单元测试，强调线程代码以寻找竞争条件等，即从开发人员角度进行测试。

质量检查人员从用户角度进行测试。QA技能是像不同类型的用户一样思考，发明奇怪的极端情况以及使难以理解的问题可重现。

不一定-程序员和测试人员都必须具有不同的技能。仅仅因为您是一名优秀的程序员，并不意味着您就可以成为一名优秀的测试人员（许多人不了解，但是成为一名程序员并不能自动使您成为一名测试人员）。

优秀的测试人员需要具有真正的恶魔般的技能，能够完成软件原本不打算做的事情，但可以期望用户在现实世界中做。这需要技巧，耐心，发现哪里出问题的能力，对用户心态的理解以及许多其他因素。

请注意，我用的是程序员和测试员一词-但是，如果您是软件工程师，但尚未决定要成为程序员还是测试员，那么它既包含这两个方面，因此是的，您至少应该在这两个方面都有经验在您做出决定前的最初几年。

这并不意味着您会聘请经验丰富的程序员并让他测试一段时间，只是为了让他了解质量检查工程师的工作量。

我的建议给您带来了一些潜在的问题：

1）如果您建议您在短期内让新手软件工程师进入质量检查部门，这是否会产生相反的效果？-他们可能会认为QA是您的新手，而您却不了解自己的工作-毕竟，这就是他们的工作方式。

2）成为一个非常糟糕的测试员一段时间并不一定会教给他们任何有价值的东西。但这可能会使他们以后变得难以教each，因为他们会假设自己现在已经了解所有测试，因为他们曾经在测试部门工作了6周。

3）鉴于他们显然只会待一小段时间，并且质量检查部门会知道这一点，因此也很可能只给他们相对不要求的，简单的任务，几乎不需要监督或理解，但会使他们忙。这只会增强1和2。

4）如果您想避免使用1、2和3，您将如何说服测试部门值得投入大量精力来教导和监督甚至对测试不感兴趣的人？（我可以告诉您，与一个尚未被选拔测试能力的人一起工作需要花费大量的时间和精力，您已经有几个星期没有为测试团队提供额外的资源了，要求他们在教您的新手时失去他们最有经验的人之一，数周。

综上所述，我认为您的总体目标（提高新软件工程师对测试的理解）确实很棒。我认为Greg的建议更有可能实现-使您的开发与质量检查团队紧密合作，并努力消除团队之间的障碍。（我目前在一家测试人员和程序员在同一团队中的公司工作，这确实很棒，而且我再也不想回到单独的团队中工作了。）

如果您仍然热衷于让程序员在QA任职-这是一个建议：以身作则。先走吧 也许让他们的团队成员在已经很不错的时候就可以做些事情，并希望通过与专门研究重叠领域的其他团队每周花一点时间来获得额外的优势，例如测试，DBA等。像这样展示它，那么您将有更多的成功机会。

我已经找到了一条与您通常所见相反的职业道路。我最初是为具有科学挑战性的物理学提供软件支持的，然后最终为一家计算机公司从事体系结构，编程和算法的交叉工作。在那之后，我做了几年主要工程代码的性能优化，但即使是那笔工作也花光了。现在，我即将退休，正在对同一代码进行质量检查。它是挑战和苦力的结合。我们有一个非常精明的新手，他100％地致力于错误修复，而我花了很多时间与他合作。这是一个充满挑战的职位，您可以学到很多东西。在这一点上，我对专业发展的主要兴趣是对我的双胞胎男孩，他们是理科大学新生。因此，我对学习（或重新学习）与他们的职业有关的东西产生了新的兴趣，尤其是应用数学。现在，我对质量检查/验证感到担忧，我对事物有不同的看法。在上个四分之一世纪中，速度，速度，速度不惜一切代价。

软件测试是破坏性的过程，而不是建设性的过程。但是程序员认为对他们的产品具有建设性，以确保产品按时并在预算内完成。如果软件开发人员认为自己的产品具有破坏性，那么下一步将是谁来构建产品。因此，软件开发周期的每个部分都必须由开发周期的每个部分中分配的人员完成。如果您从事两个或两个以上的领域，那么可以肯定您在任何一个领域上都不是完美的，那么请程序员或QA或任何其他选择做一件事情，然后在其中完美。