嗨，我叫Maksim Plavchenok，我在Bercut工作，进行集成测试。 9月，我和我的团队通过了一个重要的里程碑：由于进行了针对移动运营商发布新版计费的集成测试，我们收到了零错误。我们去了两年。今天我想告诉大家，我们如何实现目标。
基于集成测试结果的零错误-在这里，我们谈论的是在操作员方面通过业务验收测试新功能。关于此测试如何工作的几句话。
我们按计划每年发布6次新版本的计费软件。发货日期是事先知道的。在撰写本文时，我们已经计划了明年的发行日期。
这种特异性与蜂窝运营商争相推向市场的时间有关。主要原则：订户应定期接收新的计费功能。通过智能手机付款，在更换运营商时节省号码，出售未使用流量的能力-更新可能会有所不同。
“我们可能不知道一年中将确切发布什么，但是我们知道发布更新的确切日期。” 因此，可以保持所需的更新节奏。
在计费开发方面，约有70个人参与了发布。这是5到6个团队，每个团队都有自己的专长：分析，开发（几个团队），功能测试，集成测试。
是的，我们在计费项目上有一个瀑布。但是，当前的故事不是关于我们如何从根本上将开发范式从瀑布更改为敏捷，反之亦然。每种开发方法都有其自身的优势，并且在适当的条件下是好的。我想不在本文讨论范围之内进行讨论。今天，我想谈一谈进化开发：我们如何在现有开发方法的框架内，在发布接受期间实现零错误。
不适区
两年前，在所述故事开始时，我们有以下图片：
- 开发链末端的团队不堪重负；“是时候向下一个团队献礼了，而上一个团队才刚刚开始其工作的一部分”；
- 测试周期结束后，客户可以发现大约70个错误。
根据集成测试结果发现的错误可能很小（“部分消息显示为破折号”），甚至可能是严重错误（“没有过渡到其他关税”）。
我们决定更改此对齐方式：我们设定了一个目标-新功能的业务接受度为零。
一年后，我们能够将错误数量减少到10-15，到2020年中期-减少到2-3。到了9月，我们设法达到了零目标。
我们在以下几个方面进行了改进：工具，专业知识，文档，与客户，团队的合作。改进的重要性各不相同：了解客户的具体情况和流程很重要，迁移到新的规模以评估任务的复杂性是可选的，而团队合作的精神至关重要。但是首先是第一件事。
成长点
主要的集成测试工具是测试台。在那里模拟订户的活动。
共用摊位
生产中的转储会被卷到测试台上，以便您可以在尽可能接近的条件下进行测试。
要注意的是，我们的展位和客户的展位上的垃圾箱可能有所不同。操作员进行转储，并将其传递给我们，我们测试新功能，捕获并修复错误。我们将完成的功能提供给客户，另一端的同事开始测试。我们和他们的垃圾堆的相关性可能有所不同：例如，我们在7月对运营商进行了测试-例如在8月。
差异并不重要，但仍然存在。这导致这样一个事实，即在客户方面进行测试时，可能会出现我们没有的错误。
我们做了什么：我们同意用于测试的数据模式将是相同的，并且总的来说，我们将有一个共同的立场。
转储延迟仍然存在，但是我们已经配置了使延迟最小的基础架构。因此，我们能够减少由于测试和生产环境之间的差异而导致的错误数量。
测试前检查设置
当我们向操作员提供新版本的软件时，为了在客户方面进行测试，我们需要进行设置。配置新功能，可能会进一步自定义旧功能。
我们写了文档来告诉您所需的设置。只有此处的手册才能传达失真的信息。该文档是由人编写的，由人阅读的，并且在与人沟通中存在误解。
这就是我们软件的特殊性：在灵活性和可用性方面对设置有很高的要求。设置很复杂，并且没有额外的交流，并非总是能够仅通过文档来传达所有必要的信息。
结果，可能无法始终正确执行设置，从而导致在操作员侧进行测试时发现错误。分析时，我们发现这些不是软件错误，而是设置。这样的错误浪费了宝贵的时间。
我们做了什么：我们介绍了一种在操作员站进行测试之前检查客户方设置的程序。
步骤如下：客户选择我们在配置好的展台上展示的箱子。我们进行测试。如果有错误，我们将立即予以纠正；如果不是，则测试通过。
这种方法使我们能够减少集成测试过程中与不正确设置相关的错误数量。
有关文档的其他交流
除了在手册中描述这些设置外，在测试之前检查设置是围绕文档进行其他交流的一个示例。还有其他。
例如，我们做到这一点，以便在每时每刻都有我们身边的专家，客户可以向其寻求有关文档和整个系统的问题。就像是我们的高素质专家提供的专用技术支持电话一样。
我们的技术作家组织了研讨会，以培训客户员工有关新功能的知识。
文件转移的过程变得不那么分散，更加连续：新信息，澄清，建议现在可以在“主要手册”“装运”之后分部分发送；根据其出现或按需。
所有这些使得可以更好地通知客户有关新功能的信息，从而减少了集成测试中的错误数量。
有关使用第三方系统的专业知识
要开发计费，我们需要能够跟踪流量。为此有单独的PCRF系统。呼叫计入一个数据库，SMS计入同一位置，通信量计入另一个数据库。并且有专门的软件可以同步所有这些。
同时，PCRF系统是第三方专有软件。那就是一个黑盒子：我们在那里发送数据，我们收到一些回报，但我们无法控制内部发生的事情。而且，我们不能在那里进行任何更改。
这种一致性限制了我们定位和修复与流量相关的错误的能力。
我们的工作：我们建立了一个单独的内部PCRF知识库。每个事件，每个自定义选项，每个见解-团队均记录并共享所有内容。
结果，我们成为PCRF系统的良好用户，我们可以对其进行自定义并了解其功能。这样可以节省简单事件的时间。当然，对于复杂的情况，我们仍然会向系统开发人员寻求帮助。
更多看台
测试移动运营商计费的另一个功能是自定义脚本可以随时间扩展。我们要测试的完整脚本可能需要几天甚至几周的时间。
在测试阶段很难等待几天或几周。实际上，要检查这种情况，通常通常只是时候在数据库中放松一下。
要倒带时间，您需要关闭除您自己的会话以外的所有会话。我们遇到一种情况，有条件的情况下，有20位测试人员可以申请两个测试台，每个人都希望缩短时间。这是队列。排队的可能性是，在商定的软件交付日期之前，我们可能没有时间正确检查所有内容。
我们的工作：为每个测试人员设置一个单独的架子。
这使我们能够消除由于“我该轮到我的展台了，没有时间”而发生的错误。
虚拟化
展位准备不是一个快速的过程。您需要连接到运营商的网络，请求访问权限，仅此而已。完整的过程可能需要长达数周的时间。减少准备展台时间的努力是朝着实现零误差目标迈进的重要方向。
我们所做的：启用虚拟化。
复制具有所有必要设置的虚拟机，预安装的软件并自动执行此过程有助于将准备工作台的时间减少到“一天之内”。
规划
集成测试中的错误也是发布计划中计算错误的结果。在固定发布日期时，我们摇摆了很多，但并非一切都按时完成。
我们的工作：介绍每个开发阶段的临时截止日期。“如果您知道结束日期，那么您就知道每个中间日期”-这一原则帮助我们更好地控制了向发布目标迈进的速度。
并行支持和发布
在我们的旅程开始时，有一种情况是上一个版本的“债务”与下一个版本的冲突。接受之后，错误就出现在客户一方，所有人都去修复它们。
同时，发布时间表没有变化。因此，当需要解决下一个发行版时，我们仍然可以继续处理上一个发行版。
由于团队中有两个小组，因此有可能更改情况：谁来解决验收中的错误，谁来按计划处理新版本。
分裂是有条件的：不一定有一半，这里有一半。我们可以根据需要在小组之间转移人员。从外部看，好像什么都没有改变：这是团队中的一个人，在冲刺期间他研究了错误和新功能。但实际上，从“现在我们可以呼气”类别中选择单个组了。每个小组的重点以及小组之间工作的并行化对我们有很大帮助。
按时间顺序排列，这是我们在事后确定的第一个增长点之一。在这里，我的故事涉及有关主要乐器的部分。
主要工具
对我们最大的帮助是诚实的事后验尸。
有人称其为回顾性，有人称其为-对结果的分析；在我们的团队中，“事后验尸”一词陷入了困境。本文中描述的所有改进都是在事后发现的。
原理很简单：发布了一个版本，您需要聚在一起并诚实地讨论一切。听起来很简单，但是在实现过程中存在一些缺陷。在“不成功”的发布之后，团队中的人的心情是“没有时间time舌，您需要做些事情”。有人可能会事后验尸并保持沉默（因此无法提供某些可能有用的信息）。
在朝着实现零错误的目标的方向前进了两年的时间里，我们已经针对如何进行验尸制定了许多原则。
- 组装完整图片
我们邀请更多的参与者。开发人员，测试人员，分析师，经理，执行人员-任何想发表意见的人。从组织上讲，并非总是可以聚集所有人。没关系，它也可以那样工作。重点不是要拒绝同事的参与，因为“在我们团队中我们正在总结结果，您在您总结中”。与展位，代码，流程，互动互动-我们努力不遗漏任何方面。
- 不要一次抓住所有东西
好的，根据事后检验，我们得出了30个增长点。多少钱才能上班？也许我们可以解决直到下一次？“ pick 2-3”格式对我们来说效果最好。在这种情况下，有一个重点，并且团队中人员的努力没有分散。最好不要做很多，但是要比做很多，但不要忘记。
- 格式不明智
进行验尸的方法很多。促进实践，来自设计思维和横向思维的技术，Goldratt的技术和其他受尊敬的专家。根据我们的经验，常识足以开始。我们记下了问题，将它们分组，选择了几个集群，将其余集群撇开（参见上一点），进行了讨论，确定了计划。当有一个共同的目标时，找到共同的语言并不难。
- 上班
也许这是主要原则。验尸结果之后的改进清单多么有希望和令人信服，如果它不起作用，那么一切都是徒劳的。我们同意，然后我们就这样做了。是的，还有其他紧急事项。但是我们也有一个目标，并且我们希望更加接近它。
验尸可能会很痛苦。即使以建设性的方式谈论失败也不容易。但是，对抗不适是值得的。我敢肯定，如果没有验尸，我们将无法提出并实施所有有助于实现版本零错误目标的东西。
最重要的工具
事后调查允许您找到实现目标的手段，但是如果您仔细研究它，那么它也可以称为更高层次原则的结果。
最重要的工具是团队参与。
参与有工具性的一面。例如：
- 如果我们加班，老板就在团队旁边，用手帮助；
- 如果您通过跟踪进度使团队振作起来，那么您可以找到视觉指标（错误数量并不难）。
并且本着同样的精神。
参与还难以正式化-与团队分享对成功的信念的能力。毕竟，我和我的团队并不仅仅是查看公司价值观的小册子，而是在那里看到“更加团结”，并决定在宾果游戏中找到解决方案。我们已经看到了一些示例，这些示例说明如何通过共同努力实现具有挑战性的目标。我们团队中有人相信成功，并试图将这种信念传达给他们的同事。剩下的就是技术问题了。
人是最重要的。
该发行版中有许多目标可以实现零错误的目标。改进文档，提高对客户问题的响应速度和质量的工作有所不同。这次，我尝试仅分享一些示例并讨论基本原理。
在发布质量和上市时间优化方面，我和团队还有很多工作要做。使结果定期可重现，在集成测试中的错误为零，自动进行回归。
如何实现这些目标仍有待观察。但是，我们现在可以肯定知道的是：我们一定会进行事后调查，并根据动机实现增长点。我们将尝试利用参与团队所拥有的机会。
希望其中一些对您也有帮助。