当谈到构建高质量的产品时，作为QA，我们可以从这个问题开始:“什么是质量?”它经常在学术上、哲学上或ISO定义上得到回答。但我想以一个大家都知道的产品为例:松饼。

什么样的品质才能做出高品质的松饼?当然上面还有巧克力屑!让我们直接来看看与质量保证的第一个比较:就像在松饼上涂上巧克力一样，许多团队只是在编程之后才开始关心软件的质量。两种情况下的问题都是:松饼(软件)中没有巧克力(质量)。

在本文中，我们希望了解一些方法和过程，这些方法和过程向我们展示了如何在软件开发中尽早关注质量，或者换句话说，如何将巧克力直接烘焙成松饼。

正如您可能猜到的，这将显著增加常规“QAs”的工作范围，从而使我们从“质量保证”的角色中脱颖而出，成为真正的“产品质量专家”。

如何在流程的变化中提高质量

如果我们仔细观察一个典型的敏捷团队的过程步骤，我们可以看到其中的细节。

在第一步(“分析”)中，我们计划创造价值。我们为此写了一个故事，然后将其放入一个“backlog”中——因此没有立即对它做任何事情。换句话说:我们在浪费时间。在最好的情况下，分析的故事在实现时仍然是最新的。通常，故事在这个时候已经过时了。在下一步(“开发”)中，我们将计划好的价值添加到产品中。然后，故事在流程步骤中再次等待(“等待QA”)，所以在这里，我们也只是在浪费时间。团队等待质量分析师(QA)检查计划的值并将其交付给用户(“在QA中”)。

作为QAs，我们对“backlog”列没有什么影响，但是“等待QA”是“我们的”。为什么我们应该在团队中有一个过程步骤，其中唯一发生的事情就是浪费时间?如果我们将“等待QA”列与另一个工具(正在进行的工作限制)配对，那么删除“等待QA”列将对团队工作的速度和质量产生非常积极的影响。其思想是这样的:如果没有“等待QA”专栏，开发人员就没有空间在实现完成后留下一个故事，因此不能开始一个新的故事。因此，开发人员必须确保将故事传递给可用的QA。这种强制切换便于直接沟通:QA从开发人员那里接收有价值的上下文;开发人员可以利用与QA的对话来检查特定故事的所有验收标准是否都得到了满足。这段对话已经是质量的一大胜利。

我们在不同的项目和不同的上下文中使用了这些限制。在一个案例中，我们能够将故事的“分析”周期从13天缩短到4天，而不需要任何人“更努力”地工作，也不影响质量。由于开发中较少的故事不需要持续的上下文更改，因此，故事可以更快地完成。“在制品”的限制对团队的集中有积极的影响，因此不仅对上市时间，而且对产品的质量也有积极的影响。

分析人员的协同作用:业务和质量如何协同工作

要真正与业务人员(业务分析师、产品所有者或产品经理)合作，理解所有涉及的视角是很重要的:我们的业务分析师(BAs)通常非常积极地快速发布软件，因为较晚发布(软件)产品会导致更高的成本和更低的收入。

另一方面，QA的工作是确保一个可靠且几乎没有错误的产品被引入市场。

挑战在于找到速度和质量之间的平衡。为此，NASA曾经分析过错误产生的确切成本。

图1:错误的代价

在生产中，很容易发现错误成本激增的时刻。这不仅是因为服务器被称为“生产”，还因为到达生产系统的bug存在时间很长，因此成本更高。但无论成本大幅上涨的确切原因是什么，一个典型的反应是在投入生产前彻底重新检查所有东西。这些是我们CI / CD系统中的自动化测试用例。

但是，如果您更仔细地查看图表，尽早发现缺陷并从一开始就交付高质量的产品似乎是最经济有效的，这是在起草需求和分析案例的时候，而不仅仅是在测试的时候。

以我的经验，这是最好的时候，QAs和BAs实际上坐在一起。当他们一起处理需求，并在简短的计划会议上向团队展示这些需求时。通过这种方式，关于需求的知识(包括“边缘案例”和“sad路径”)可以在实现之前与整个团队共享。QAs可以确保最重要的“sad路径”已经被考虑用于实现，因此，也可以自动测试回归。这样，手工测试的工作量就大大减少了。与时间压力下的代码冻结测试相比，我们推出的产品质量更高，上市时间也更早。

要积极主动

理想情况下，开发人员与QAs一起工作，按照测试金字塔（https://martinfowler.com/articles/practical-test-pyramid.html）的原则，从单元测试级别一直到所需的端到端测试，构建回归测试。然而，无论这些测试在设计时多么复杂，它们总是在实现之后执行。

为了从一开始就提高质量，我们尝试将一个简单的规则应用到所有团队:每个提交都投入到生产中。

设置此规则可以提高质量:当QAs不再是可能错误的最后守护者时，开发人员将花费更多时间确保他们的测试涵盖最重要的内容。而且，由于QAs是测试专家，开发人员和QAs之间的推拉关系被这个新规则逆转了。此前，门票已被推到QAs进行测试。现在，开发人员正在向QAs咨询关于如何最好地构建测试的建议——尤其是在实现之前。

第二个好处是你在紧急情况下有更大的灵活性。通常，在经典的发布管理中，对于如何执行一个发布，您有一个复杂的计划。如果出了什么问题，有一个热修复—选择—发布—流程，它绕过了团队中的大多数安全措施和质量控制。这听起来不太可信。

我们不再需要在我们的团队设置。如果发布周期不超过30分钟，我们就可以快速响应生产问题，而不需要热修复程序或分支。我们甚至不再需要回滚策略。

真正有趣的问题是如何设计监视，以便您能够更早地发现生产中的问题。这至少包含应用程序错误数量的可视化，以及服务器或数据库响应时间。如果你想达到真正的专业水平，你可以考虑完全自动化的异常检测。

因此，在使用特性切换以一种非常受控的方式启用新特性的同时，发行版的问题明显减少了。我们不仅能快速为用户提供新的价值，同时还能实现更高的质量。

创造一种接受错误并从错误中学习的文化是提高质量的根本

每个团队都会犯错，这是人性使然，也是好事，因为我们从错误中学习。作为QAs，我们非常关注错误的风险和影响，它们可以帮助团队在安全的环境中快速地犯错误，从而使团队能够非常快速地学习新事物。这不仅增加了团队的安全性和信任，提高了软件的质量，而且几乎是意外地增加了团队的创新潜力。

我们非常密集地使用的一种方法是结对编程，这也是团队不断要求的QAs方法。它特别帮助我们避免小的失误——这是必然发生的有时。有效的损害控制是两个人的“配对”，其中大多数是开发人员。

但错误并不是结对的唯一动机。你知道当你尝试了一些新东西并理解了它是如何工作的时候，你会有一个“啊哈时刻”吗?我们试图通过“尝试”(故意挑起错误)让团队尽可能轻松地经历这样的时刻——并在两人内部谈论它!

最后，确保你的团队玩得开心。

“有趣”，你可能会问——“真的吗?”

是的。想象两个不同的团队。在第一个团队中，人们非常兴奋，他们快乐地工作，早上互相打招呼，他们交流和讨论他们正在做的事情。然后是第二组人，他们更喜欢在早上拿到一个待办事项清单，然后在剩下的时间里一个人待着，直到他们完成了那个待办事项清单。你认为哪个团队会开发出更好的产品?哪个队会犯更少的错误?哪个团队更有可能按时交付?

质量专家通常是开发人员和业务之间的纽带，我们连接人员和他们的观点，我们帮助建立信任的文化。这些都是构成伟大文化的小因素，而我们这些高素质的专家通常就在其中。

将所有这些结合起来:一个积极的团队氛围，QAs和BAs之间的紧密联系，一个出色的形状的测试金字塔，以及一个实际上使团队能够快速交付软件到生产中的过程，最终将导致一个更好、更快、更强的高质量产品。

本文：https://architect.pub/faster-better-stronger-building-high-quality-product

讨论：请加入知识星球【首席架构师圈】