混合开发和分离开发_开发保证：开发人员和质量保证人员之间的混合体

混合开发和分离开发

在我的整个职业生涯中，我看到开发团队和质量保证团队之间发生了许多争执，他们争论着围绕缺陷的无数个小时。 在书呆子群体中，这些战斗相当于历史上最伟大的战斗，没有光荣的斗殴。 有些人可能会把最好的讽刺带进战场，尽管这并不是他们的长处。

“为我工作”是开发人员的经典回应之一，其结果类似于以下内容；

然后跟着在个人之间来回飞行一些影射。 可能有很多原因，例如；

• 由于缺陷是群集的，因此只能在类似生产的环境中进行复制，并且在仅运行独立服务器实例的开发人员机器中仍可以正常工作。
• 测试环境中缺少配置
• 特定于特定环境

还有许多我们将不详细介绍的内容，因为这不是本文的目的。

接下来是“按预期工作”的困境。 这是一个棘手的问题，因为可以从不同角度看待它并得出不同的结论。 对于开发人员而言，如果从未将其指定为要求，则它不应是有效的缺陷。 对于质量保证人员而言，这是一项非功能性要求，应在交付的解决方案中予以满足。

缺陷可以采取多种形式，但是最终结果是，缺陷通常导致开发人员和测试人员之间发生冲突。 在我的职业生涯中，我也遇到过这些不愉快的冲突。 如果一个人回顾过去，就会发现总是存在着利己主义问题，这导致双方都没有放弃自己的立场。 父亲给了我一个非常重要的报价单，我仍然把它放在办公桌前。 尽我所能向您展示；

将所有这些SLA，缺陷比率，缺陷密度度量放在一旁，如果您真的查看问题，对于我作为开发人员来说，我不希望测试人员在我的代码中发现任何缺陷。 但是我们都知道100％完美的代码就像找到独角兽一样容易。 我要在这里得到的是从开发人员角度来看已报告的缺陷的观念发生了变化。 您必须知道，您永远不会产生零缺陷代码。 当确实在所处理的代码上报告了缺陷时，最好将其作为学习的机会，并对将来需要做的事情建立更多的自我意识，以避免此类问题并向前迈进，而不是向前迈进与测试人员试图捍卫缺陷的斗争毫无结果。 质量是开发人员应该灌输的东西，而朝着这个方向迈进的第一步就是在测试自己的代码时停止以开发人员的身份思考。 通常，我们会过分关注代码的技术细节以及您测试过的各个分支的代码覆盖率。 不要误会我的意思，这很好，但是我要努力做到的事实是，您需要查看代码最终提供的业务功能，如果可以令人满意地做到这一点。

我只喜欢主动的软件开发方法，因此在我工作的地方，我们做了一些质量检查，这些检查已大大减少了两个团队之间的这些不愉快的对抗，从本质上讲，这应该被视为一个旨在提供质量的团队给客户的解决方案。

在这个阶段，我们作为一个团队，研究为给定功能部件创建的设计文档。 当我们遵循敏捷过程时，设计文档具有分解为用户故事的功能。 当我们让整个团队参与设计审查时，它会提出不同的意见和疑虑，这些意见和疑虑提供了宝贵的信息，可以更好地完善解决方案。 这导致缺陷密度的降低，并改善了个体之间的沟通，因为每个人都有所执行工作的背景，尽管每个人都可能不参与给定的设计实现。

演示/演练

在完成特定的实现之后，我们已经习惯了参与其中的开发人员应该在将其交付给测试环境之前向团队介绍其可交付成果。 由于这又涉及到整个团队，因此团队可以公开讨论任何问题或提供改进建议，然后在发布到测试环境之前可以考虑这些建议。 一方面，这使开发人员可以了解他们提供的解决方案的业务影响，以便他们可以与之更紧密地联系，当然也可以使他们在演示方面也可以微调其软技能。

发布

在这里，我们有技术主管或架构师在实际发布之前询问特定问题。 问题，例如；

• 此版本的总工作量是多少（确定要发布的更改量）
• 代码审查是否已完成并审查了评论？
• 测试成功完成了吗？
• 在测试阶段，确定了多少积极和消极的情况？
• 考虑该发行版的任何非功能性要求吗？
• 是否完成了针对核心功能的回归测试？
• 此版本上是否有重大部署更改？

所有这些问题使团队可以思考他们可能尚未考虑的方面，并在实际部署之前充当质量门。

这些阶段使开发人员能够将质量方面嵌入他们的核心中，就像感兴趣的人中的撒玛利亚人通过在所有硬件的固件中内置病毒来监视每个人的击键一样（我只是不相信这个出色的电视系列结束）。 反过来，这使我们能够在团队中创建“开发保证”人员，从而提高了团队的生产力，沟通和效率。

翻译自: https://www.javacodegeeks.com/2016/07/dev-assurance-hybrid-developer-quality-assurance-personnel.html

混合开发和分离开发