你认为软件工程师必须做一段时间的质量保证工程师是个好主意吗？

Question

我相信是的。为什么？

1. 我遇到过许多软件工程师，他们认为他们在某种程度上优于QA工程师。我认为，如果他们能在一段时间内完成QA工程师的工作，并意识到这是一套独特而有价值的技能，这可能有助于消除这种信念。
2. 软件工程师对自己的程序进行测试越好，他们的代码在软件开发生命周期的其余部分中所花费的时间就越少。
3. 软件工程师花在思考程序如何崩溃的时间越长，他们在开发过程中就越多地考虑这些情况，从而减少了最终产品中的错误。
4. 软件工程师对“完整”的定义总是interesting...if --他们作为QA工程师的时间--也许这个定义会更接近于软件的设计者。

注意，我提出上述建议时，考虑到一个很小的时间框架，因为我知道，让某人在一个不是他们被雇佣的职位上工作，肯定是失去那个开发人员的秘诀。

你们都怎么想？

Answer 1

1. 我遇到过许多软件工程师，他们认为他们在某种程度上优于QA工程师。我认为，如果他们能在一段时间内完成QA工程师的工作，并意识到这是一套独特而有价值的技能，这可能有助于消除这种信念。

一个好的软件工程有质量背景，包括测试、度量和统计。任何从事任何类型的软件开发的人都应该知道(如果不熟悉)维护高质量的源代码和生产/维护有效的测试用例。随着时间的推移，我怀疑任何软件开发人员都会理解质量的不同方面--代码质量、可移植性、可维护性、可测试性、可用性、可靠性、效率和安全性。

软件工程师可能关注生命周期的一个特定方面--需求工程、体系结构和设计、构建、测试和维护。然而，不管你的关注点是什么(无论是作为工作还是在项目的当前阶段)，记住质量是很重要的。

1. 软件工程师对自己的程序进行测试越好，他们的代码在软件开发生命周期的其余部分中所花费的时间就越少。

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

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

这是完全正确的说法。但是，同样地，也要由需求工程师来验证需求中是否存在冲突，架构师要确保设计实际解决需求，等等。每个人都应该试着在他们的工作中戳洞，然后和合适的人一起工作，把他们封得既好又紧。

1. 软件工程师对“完整”的定义总是interesting...if --他们作为QA工程师的时间--也许这个定义会更接近于软件的设计者。

“完整”只能根据需求来衡量。要么满足了需求，要么项目完成了，要么存在不完整的需求，而且项目没有完成。任何其他的完整标准都是无用的。

Answer 2

让程序员对他们的代码负责，并要求他们修复自己的bug，就可以解决这个问题。还有奖金和/或工作的损失。

这并不是说这种经历没有帮助，但你能用这种思路走多远呢？技术支持，销售，Beta用户，擦洗厕所(这将是一种谦逊的体验)。

Answer 3

"...have做QA工程师.“你让它听起来像是对抗性的或惩罚。

我是一名软件开发人员。我认为做QA工程师也是我工作的一部分，尽管我们有QA部门。我的工作是交付完成某些事情的软件，为了做到这一点，我必须编写单元测试并确保软件通过它们。

我是我们的质量保证部门的合作伙伴。我的目标是使他们的工作更容易，就像他们的工作是帮助我实现我的目标，交付软件，做它应该做的，从而使我的生活更容易。我认为它们是我的第二套眼睛，有点像一个安全网，就像我做单元测试一样。

我选择开发软件，并希望开发软件。如果有经理来找我，告诉我我不能这么做，不得不做QA，我会告诉他们，他们需要找到一个新的软件开发人员和QA人员，因为我不会在那里工作。对于我的代码来说，我是个无赖，但是创造性的过程和编程的难题/挑战对我来说是非常重要的。如果我不能写代码的话，我宁愿回去开叉车，因为在一个没有创造性和被挑战的公司环境中，对我来说绝对是地狱。

一般来说，您提供的选项听起来非常对抗性，让我怀疑您是否与一些糟糕的开发人员有过一些非常糟糕的经验。在我看来，开发人员必须始终意识到质量问题和测试，并且应该为他们的工作感到自豪，直到他们认为它通过了他们的单元测试中的严格测试之后，他们才会认为它已经完成了。如果我有一个同行，或者是一个团队的技术带头人，并且有一个开发人员在QA上表现出“正直”，他会发现我把他拉走了，要求他纠正态度。如果软件交付硬币的双方不能合作，作为一个团队，就会有真正的文化问题。我不想在那里工作，人力资源和高层管理人员也需要了解。