今天，我们正在观察瀑布式开发模式如何逐渐消失在世界各地。 她不因自己的沉重和对变化的不良反应而受到爱。 这直接影响到产品的相关性并增加了TTM（上市时间），从而导致了额外的成本。 开发人员正在敏捷的轨道上进行重建，我们也不例外。
敏捷方法最初是为小型团队创建的，这些团队以端到端的方式生产交钥匙产品，并对其质量负责。 但是，如果您开发高度敏捷的银行系统，使数十个敏捷团队能够工作，该怎么办？ 如何获得对产品进行长时间全面测试的信心？ 在这篇文章中，我们将分享我们对这个问题的解决方案。
每个人都以不同的方式解决问题，但通常归结为测试自动化。 正在开发对存根的测试，形成相邻团队积压的一般规则是团队间交互的框架，例如SAFe。 结果，由于积压的同步，相关产品团队可以一起编写和执行测试，包括集成测试。 我们有这样的框架。
但是现在，我们取代了复杂而高度关键的银行系统的所有者。 毕竟，如果他们自己直接参与数十个负责任的敏捷团队的工作，那么谁负责整个产品的质量呢？ 您需要确保生产不会失败。 引入其他测试？ 嗨，瀑布，再见，TTM。
没有完美的解决方案。 在这种情况下，我们将始终在方法论原理与结果的保证可靠性之间发生冲突。 这是我们发现的妥协。
质量门
如果您的产品的特殊性假定它与其他产品没有完全隔离，那么在联系点上，您应该遵循一个规则-遵守最低质量要求。 该代码应包含在单元测试中，并且不应包含信息安全的严重缺陷，分发时应在分发时进行冒烟测试。 没有锡，但是每个人的要求都是强制性的。 它们的实现是通向常规测试的通行证。
因此，一般而言，
Quality Gates的做法看起来像是内置在每个系统的devops管道中的一组自动检查。 实际上，它反映了换档测试的趋势，这种趋势现在经常在devops框架中谈论。
我们与所有团队就许多检查和质量关口达成了一致，他们必须在生命周期的各个阶段中通过这些关口。
编码方式
在构建代码之前，您需要进行强制性的静态分析，检查代码是否符合特定编程语言的标准。 以及单元测试的覆盖范围。 为此有不同的工具。 例如，我们喜欢SonarQube。 通过这一质量保证后，团队可以确保他们在早期阶段没有违反一些基本规则。 例如，避免了重复，这增加了代码的复杂性和出现问题的可能性。
组装前的第二项测试是IS检查。 存在识别代码中的IS问题的普遍接受的惯例以及可以扫描代码并识别危险位置的工具。 例如，错误声明的变量可能会导致生产问题。 在这里，我们同意不允许在编写代码的阶段可以透漏的一切，渗透测试和更复杂的检查。
发行版本
组装分发套件时，我们总是检查结果：组装正确，所有服务启动并按预期工作，分发套件可以安装在所需的环境中并且可以正常工作。 这样的功能验证测试消除了测试人员和开发人员之间潜在的误会。 在瀑布式实践中，过去通常是开发人员完成工作，将分发工作交给测试人员，然后安装到支架上时，结果证明组装甚至没有开始。 然后整个周期被打破，开发被拉长了，什么也没有发生。
我们的整合互动非常复杂。 重要的是不要打破可以检查其他团队的立场。 我们可以这样做是因为分布不均，而且展位邻居会在我们之前知道这一点-我们只会破坏他们的整个工作过程。 此外，这可能会破坏测试数据。 而且他们的准备工作也要花钱，并且要花费大量时间。 特别是在涉及匿名用户数据时。
烟雾测试
由于分发套件安装在每个测试台上，因此通过了一系列简单的烟雾测试。 在系统测试站，将测试发行版的功能。 此外，分发工具包放在集成测试台上，在集成测试台上测试了集成交互。 它还运行一组烟雾测试。 如果分发没有通过他们，他将无法进入下一个阶段。
使用这些质量门，我们可以初步了解分发质量。 如果烟雾测试成功，则团队开始测试。 如果分发套件在此阶段未通过烟雾测试，则很可能不会通过手动测试。 在这里，仅当程序集可能准备好进行舞会时才分配它。
质量门作为框架
我们努力确保质量门成为管理大量敏捷产品开发质量的完整框架。 如果团队经常无法通过甚至强制性的质量关卡，则表明存在一些问题需要讨论和解决。 另一方面，如果某个团队已经掌握了基本的质量门并将其构建到内部程序中，则它可以走得更远，并包括其他质量门。
将来，我们计划推出新的强制质量门。 并且是可选的，以便每个具有足够成熟度的团队都可以选择所需的内容。 例如，如果您想确定集成测试站点分发包的稳定性，则团队将独自承担质量保证。 如果您需要确保复杂的多组件程序集不会妨碍部署，则其他人会采用它。 有人倾向于前端的安全性，有人倾向于检查负载测试，机架的可用性，响应，有人倾向于集成或验证某些数据。 每个团队将能够为他们的案件找到质量的大门。
重要的是要注意，质量门不是测试的替代品，而是
主要的控制工具 。 没有人取消测试。 这里的主要任务是使产品质量不佳对其他团队造成的损害尽早降至最低。
包含质量门的第三方管道的示例实施质量门的结果
首先，我们提高了生产周期的稳定性。 通过采取行动，我们可以立即检测到关键的功能错误。 花费在各种测试迭代上的时间更少；可以更早地发现缺陷，因此消除缺陷的成本更低。
前置时间减少了-从特征编码开始到在生产中实现所需的时间。 由于我们减少了将分发套件交付到工业环境中的停机时间，因此TTM工程阶段的稳定性得到了提高。 我们花了相同的时间进行测试，但是由于展台倒塌以及需要重新分配发行版的缘故，我们没有任何停机时间。
可用于测试环境的时间增加了。 以前，您可以在上面放一个装配，而忘记一个星期。 同时，相关团队无法在此环境中进行测试，因为您的构建有缺陷，并且只有一周后您才能知道。 现在，当您将组件放在地面上时，您可以自己测试是否存在最常见的问题，如有必要，请回滚，完成并返回。 不停止任何人的机会变得更高。 引入高品质的闸门还可以减少恢复机架和重新培训测试数据的成本。
您的意见
正如我们在一开始所说的那样，敏捷和集成开发原则之间的矛盾不能被视为戈尔迪式的难题。 人们只能努力确保它带来尽可能少的问题。 对于我们来说，质量门的做法很有帮助，但是，当然，我们认为这不是理想的选择。 您如何解决这个问题？ 对我们来说讨论这个问题将是非常有趣的。
Sberworks-Sberbank技术Nikolay Vorobyov-Sarmatov
感谢Mikhail Bizhan为撰写本文提供的帮助！