在构建高质量产品时，作为质量保证，我们可以从“质量是什么？”这一问题开始。它经常在学术上，哲学上或ISO定义上得到回答。但我想首先看看我们都知道的产品示例：一个松饼。
什么品质会使松饼成为高品质的松饼？当然巧克力洒在上面！让我们直接进行质量保证的第一次比较：正如巧克力在烘焙后散布在松饼上一样，许多团队在编程后才开始关注软件的质量。两种情况下的问题：松饼（软件）中没有巧克力（质量）。
在本文中，善微科技希望了解如何在软件开发中尽早提高质量意识的方法和流程，或者换句话说，如何将巧克力直接烘焙到松饼中。
正如您可能猜到的那样，这将大大增加常规“QAs”的工作范围，从而使我们从“质量保证”角色中脱颖而出，成为真正的“产品质量专家”。
过程中的变化如何提高质量
如果我们仔细研究一下典型敏捷团队的流程步骤，我们就可以看到详细信息。
在第一步（“分析”），我们计划创造价值。我们为此写了一个故事，然后我们把它放在“积压”中 - 所以没有立即对它做任何事情。换句话说：我们在浪费时间。在最好的情况下，分析的故事在实施时仍然是最新的。通常情况下，故事已经过时了。在下一步（“开发”）中，我们将计划值添加到产品中。之后故事又在一个流程步骤中等待（“等待质量保证”），所以在这里，我们只是在浪费时间。该团队等待质量分析师（QA）审核预定价值并将其交付给用户（“质量保证”）。
作为QAs，我们对“积压”专栏的影响很小，我们为什么要在团队中有一个流程步骤，其中唯一发生的事情就是浪费时间？如果我们配对，删除“等待QA”列会对团队工作的速度和质量产生非常积极的影响它与另一个工具：工作进度限制。想法如下：如果没有“等待QA”列，开发人员没有余地留下一个故事，一旦实施完成，因此不能只是开始一个新的。因此，开发人员必须确保将故事传递给可用的QA。这种强制移交有助于直接沟通：QA从开发者那里获得有价值的上下文; 并且开发者可以利用与QA的对话来检查是否实际满足了特定故事的所有接受标准。
我们在不同的项目和不同的环境中使用了这些限制。在一个案例中，我们能够缩短从“分析”到“完成”的时间段，从13天到4天，没有任何人必须“更努力”地工作而不会影响质量。由于开发中的故事不需要不断更改上下文，因此可以更快地完成故事。“在制品”的限制对团队的集中度产生了积极的影响，因此不仅对产品上市时间有影响，而且对产品质量也有影响。
分析师的协同作用：业务和质量如何协同工作
要真正与业务人员（业务分析师，产品负责人或产品经理）合作，了解所有相关的观点非常重要： 我们的业务分析师（BA）通常非常积极地快速发布软件，因为（软件）的后期发布产品导致更高的成本和更低的收入。
另一方面，质量保证的工作是确保向市场推出一种可靠且几乎没有错误的产品。
挑战是在速度和质量之间找到平衡点。为此，NASA曾经分析了错误成本的确切位置。
图1：错误成本
很容易发现错误成本爆炸的时刻：生产中。这不仅是因为服务器被称为“生产”，而且还因为到达生产系统的错误很长，因此更加昂贵。但无论成本大幅增加背后的确切原因是什么，典型的反应是在投入生产之前彻底重新检查所有内容。这些是我们的CI / CD系统中的自动化测试用例。
但是如果你仔细看一下图表，那么在起草要求和分析故事时 - 而不仅仅是在测试时 - 尽早发现缺陷并从一开始就提供高质量似乎是最具成本效益的。
根据我的经验，当QAs和BA实际上并排坐着时，这是最好的。当他们在需求上一起工作并在短期计划会议中将他们一起呈现给团队。通过这种方式，可以在实施之前与整个团队共享有关需求的知识（包括“边缘案例”和“悲伤路径”）。质量保证可以确保最重要的“悲伤路径”已经考虑用于实施，因此也自动测试回归。通过这种方式，手动测试的工作量大大减少。与时间压力下的代码冻结测试相比，我们推出的产品质量要好得多，而且市场早得多。
主动
理想情况下，开发人员与QA一起工作，将回归测试从单元测试级别一直到所需的端到端测试，并遵循测试金字塔的原则。但是，无论这些测试在设计时有多精细，它们总是在实施后执行。
为了从一开始就提高质量，我们尝试将一个简单的规则应用于所有团队：每次提交都要进入生产阶段。
设置此规则可提高质量：当QAs不再是可能出错的最后监护人时，开发人员会花更多时间确保他们的测试涵盖最重要的事情。由于质量保证是测试的专家，开发人员和质量保证之间的推拉关系被这一新规则所逆转。之前，门票已被推送到QAs进行测试。现在，开发人员正在向QA询问有关如何最好地构建测试的建议 - 特别是在实现之前。
第二大优势是，您可以更灵活地在紧急情况下采取行动。通常，在经典版本管理中，您有一个如何执行发布的复杂计划。如果出现问题，可以使用hotfix-cherry-pick-branch-release-process来绕过团队中的大多数安全措施和质量控制。这听起来并不特别值得信赖。
我们的团队设置不再需要它。通过30分钟或更短的发布周期，我们可以快速响应生产问题而无需修补程序或分支。我们甚至不再需要回滚策略。
该真正有趣的问题是如何设计监控，以便您可以更早地发现生产中的问题。这至少包含应用程序错误数量的可视化，以及服务器或数据库响应时间。如果你想达到一个非常专业的水平，你可以考虑全自动检测异常。
因此，我们发布的问题显着减少，同时使用功能切换以非常可控的方式启用新功能。我们不仅能够快速为用户提供新的价值，而且还能同时实现更高的质量。
创造接受和从错误中吸取教训的文化提供了最终的质量提升
每个团队都会犯错误，这是人性，而且很好，因为我们从错误中吸取教训。作为QAs，我们非常关注错误的风险和影响，它们可以帮助团队在安全的环境中快速犯错 - 从而使团队能够非常快速地学习新事物。这不仅增加了团队的安全性和信任度以及软件的质量，而且几乎意外地也是团队的创新潜力。
我们非常密集地使用的一种方法 - 以及团队不断要求的QAs - 是结对编程。它特别有助于我们避免小滑倒 - 这有时会发生。有效的损害控制是两个人的“配对”，主要是开发人员。
但滑倒并不是配对的唯一动机。你知道当你尝试新事物并理解某些东西是如何工作时所拥有的“啊哈时刻”吗？我们试图让团队尽可能轻松地通过“尝试”（=故意挑衅错误）来体验这样的时刻 - 并在对话中谈论它！