*Mindset Shifts For Engineers to Achieve Higher Software Quality*

看到个开发小哥写的关于测试的文章，挺有意思的，翻译了一下，观点虽不新颖，但能从开发角度去思考软件质量，格局上面是值得称赞的。原文地址：https://medium.com/@phdmeyildiz/mindset-shifts-for-engineers-to-achieve-higher-software-quality-8ef8ee00a041

作为一个刚从大学毕业的初级工程师，没有什么是比掌握越来越多的工具、编程语言等更重要的事情了。当你刚进入工程领域时，你想捣鼓点新东西，然后你想看这些玩意可以正常工作。这是职业生涯早期最大的动力来源。我也是这样做的，并把大部分时间花在这上面。我一直不太理解我的前辈们，他们更关注工作方式，而不是下一个很酷的技术。现在，经过12年的时间，我不仅理解了他们，而且在这里，我写下了我的第一篇文章，讲述了一个简单的思维方式的转变对你的项目的影响会比几十种编程语言大。

这篇文章是关于转变我们作为软件工程师的心态，在交付产品时获得高的视角，最终让客户的满意提升。下面的思维转变说明没有详细解释，只是用简短的句子写出来，我们可以做更深层次的思考。

让我们来谈谈我们需要改变的思维模式。👍表示目标思维模式，👎表示我们需要远离的思路。

哪种工作方式？

持续交付👍

• 软件总是处于可发布的状态。
• 我们可以随时进行发布。
• QA尽早介入开发流程。
• 尽早测试以避免bug的产生，并分析产品的质量。

瀑布式的敏捷 👎

• 软件需要经过完善流程才能到可发布的状态。
• 我们需要等到发布那的那个星期才能来进行发布。
• QA等到发布之前才能检查软件质量。
• 测试置后旨在发现已经开发的功能中的错误。

什么时候测试？

从一开始就进行测试👍

• 从一开始就进行测试，以增加最终结果的可预测性。
• 在开发过程中做探索性测试。
• 开发和测试同时结束。

最后测试 👎

• 以部署前的例行测试作为开发流程的结束。
• 在开发过程中可能已经引入了错误，我们的作用是找到它们。
• 首先开发，最后测试。

谁为质量负责？

每个人都要对质量负责👍

• 把质量放在前面和中心，而不是放在pipeline的末端。整个团队都要关注质量。
• bug的检测是在开发过程中同步进行的，不存在QA资源是瓶颈的说法!
• 更少的资源可以做得更多。

只有QA团队对质量负责 👎

• 把质量作为最后一道防线。
• QA成为瓶颈的可能性很大。
• 需要越来越多的资源来战胜质量问题。

何时交付？

更快、更小的交付👍

• 尽量高频率的交付少量的代码
• 高质量来自于小的、快速的、明确的工作步骤，我们可以在创造变化的过程中进行监控。

岁月静好，我憋大招 👎

• 一次性交付大量的代码。
• 当软件很复杂的时候，要验证其质量是比较困难的。

质量保证（QA）还是质量控制？

QA高于质量控制👍

• 主要关注点是高效的工作方式和建立团队间的和谐。
• 在从事任何工作时，都要考虑到质量问题。
• 不断的反馈机制来改善SDLC（软件开发生命周期）的pipeline。

只有质量控制👎

• 主要关注的是检查最终结果。
• 当出现问题时，质量成为关注点。
• 在最后的测试中收到反馈。

什么是QA？

QA是指质量协助👍Q

• QA团队从开发的开始到结束都处于顾问的位置。
• 重点是放在质量上，而不是寻找错误。
• 错误更容易修复，也更便宜。
• QA不应该发现bug。当发现一个bug时，它不仅应该被修复，而且应该调查其根本原因。
• 错误意味着SDLC过程中存在问题，这个过程需要被修正。

QA意味着发布守门员👎

• QA团队是一个测试者和bug寻找者。
• 没有改善质量的空间。
• 修复问题的成本和风险都比较大。
• QA应该找到bug，然后bug应该被修复而不需要进一步挖掘其根本原因。
• 错误只是一个软件问题。

观点

你对上面的一些思路转变有什么样的看法呢？