一年半以前，我们摧毁了测试团队：我们放弃了回归，将E2E自动测试转移到Selenium来支持开发人员，并分散在看到防止错误的功能的团队中。在梦ros以求的梦中，这似乎对我们更有用：质量方面的质量检查工作，测试提早开始，开发人员自己编写自动测试，没有人打扰他们。
但是，
一阶和二阶后果是什么
雷·达里奥（Ray Dalio）在《原则》中有一个“二阶后果”的概念。这些是我们通常无法预测的决策的非显而易见的后果。例如，在20世纪60年代，中国发动了一场与麻雀的战争。麻雀吃了谷物，以致他们不再吃谷物，中国开始寻找鸟类。在狩猎过程中，中国人共杀死了近20亿只鸟。
由于麻雀的种族灭绝，一年后收成增加。这些是一阶后果。但是没有人可以吃昆虫，蝗虫和毛毛虫，这使人们开始毁灭更多的粮食，并在随后的几年里在中国造成了大规模的饥荒。这些是二阶后果。
一阶后果是我们决策的直接后果，总是浮出水面。二阶后果微妙且通常是长期的。要了解它们，您需要思考并模拟情况。例如：
- 如果您向开发人员支付代码行数，那么将会有更多的代码，但是质量会更差。随着时间的流逝，人们将开始作弊并产生越来越多的错误代码，以获取更多的收益。这些是二阶后果。
- 如果您开始运动，一开始会很痛苦并且需要很长时间。但是一段时间（从一周到几个月）会养成习惯，并且健康和外表都会改善。这些是二阶后果。
- 如果您每个星期五都像猪一样喝醉，那么星期五晚上会很好。但是周六早上会很糟糕-这些是二等后果。如果您定期进行此操作多年，那么它可能会发展为酒精中毒和肝硬化。但是这些已经是三阶后果，并且是“一个完全不同的故事”。
我们有一个质量检查小组，并且“分散”了它
现在，我将告诉您我们如何看待一阶和二阶的后果。我们有一个由7人组成的测试人员组成的敬业团队，其中有4人编写了自动测试程序，其中3人进行了手动测试。在某个时候，我们决定拆分并分散在团队中。为什么？
因为开发人员收到反馈太迟了。
这些bug处于所有开发都“完成”，所有内容都“集成”的阶段，因此有必要检查产品是否已准备好发布。没有验收测试，它是由没有测试技能的产品分析师执行的。此外，测试人员和开发人员处于不同的领域，几乎没有互动。
显而易见（当时）的解决方案是将团队分为几个团队，负责处理系统的某些功能（部分），以防止出现错误。我们不想放弃我们的工作，因此我们决定将功能转移给开发人员。我们考虑过自动测试-我们将把它们交给开发人员，他们将进行自我测试而不会出现问题。
最初，他们决定通过“实验”对自己的假设进行检验：我们将通过自动测试涵盖回归的关键场景，并拒绝手动回归。根据经验，如果修补程序和发行回滚的数量没有显着增加，则可以认为该实验成功。这样就发生了-没有更多的修复程序。解决-不同意。
注意。该公司有一种名为Restaurant的产品。它包括所有服务和我们的巨石。该产品的目标是使所有餐厅员工的工作尽可能自动化和优化。现在我们的工作更多地集中在错误预防上。现在我们是“餐厅”产品的质量检查人员：我们开发产品的品质，我们参与任务开发的所有阶段。
一阶和二阶后果
直接后果。正如预期的那样，我们从一开始就开始参与任务的开发，参与PBR，计划，研讨会并为他们提供测试专业知识。我们变得更接近开发团队，或者说是其中的一部分，我们的问题也是团队的问题。在团队中，测试方面的专业知识，质量保证和对系统的广泛了解开始增长。反过来，我们开始专注于开发人员的工作并了解他们的痛苦。
现在，我们没有计划的是二阶后果。
没有人能驱动产品的质量。这个问题有两个方面：
- 流程质量；
- 自动测试和管道的质量。
在我们专门的质量检查团队中，我们追求质量。我们是最后一个在用户面前看到产品并了解他们如何看待产品的人。我们讨论了团队复古方面的更改和改进，并向开发团队提出了建议，以便共同决定是否应引入它们。我们监视自动测试并致力于其稳定性。
当我们分散在团队中之后，它们全部消失在某个地方。在开发团队中，我们是团队的
所有想法仅旨在改善团队状况-我们竭尽全力发布了高质量的功能，而不是高质量的产品。结果，可以将产品质量提高到新水平的根本上强大的解决方案就不再出现。
编写自动测试的能力已经消失了-自动测试开始弯曲，并且经常在不更改代码的情况下下降。在团队解散时，手动测试人员才刚刚开始掌握自动化的基础知识。事实证明，测试人员和开发人员都没有任何专业知识。此外，当编写这些测试的人员转到开发，产品管理以及其他人辞职时，专业知识也变得一头雾水。
我们不可靠地知道我们拥有什么自动测试，它们涵盖了什么，我们不知道它们如何开发，发展，添加或删除-一切都留给了开发人员。结果，当需要在自动测试中查找一些信息时，没有开发人员便无法解决这种问题。
开发人员的额外工作。很难成为开发人员。如果以前他们曾经写过经过“神奇”验证并投入生产的产品代码，现在他们需要自己编写测试，进行编辑和稳定化。在PBR，我们确定测试应涵盖哪些方案，开发人员自己选择自动测试的级别。
开发人员通过接受的几个阶段走到
否定...所有Dodo IS版本均由开发人员开发。他们组织流程，与负载测试团队进行沟通，查看日志并在发布期间进行监视。发行发行版的开发人员面临着红色测试，并未试图找出其原因，而只是重新启动了管道，直到其变为绿色5-7-10次为止。这是因为对自动测试不信任。
我发现的最大重启次数是44次！在我看来，我们在其中一项“不要发布带有红色测试的版本”中采用的规则。如果测试为红色，请找出问题所在。如果问题出在测试中，请对其进行修复或签名，然后制作一张卡来解锁测试并将其添加到待办事项列表中。”
愤怒：开发人员发誓要接受我们的测试，他们说他们
没有讨价还价和沮丧，接受很快就来了：开发人员现在可以自己为UI和API编写E2E测试，以稳定和改进它们。
出售的虫子数量开始增加。非关键错误开始渗透到生产中。有几个原因：
- 我们的自动测试并不涵盖所有功能，而仅涵盖关键功能。并且没有更多的手动回归测试。
- 所有团队的QA工程师不足。团队没有测试能力，因此他们没有适当注意测试
结果，我们开始意外发现生产错误。它们并不关键，但是总体上没有想象到其中的多少。
我们如何解决这些问题
也许另一个团队可以预测所有非显而易见的后果，但我们不能。几个月后，我们做出了决定，并开始消除后果。
建立了餐厅QA行业协会或实践社区，其中包括所有餐厅QA。社区的目标是提高整个产品的质量，将良好的测试实践传播给所有产品团队。这是一种结合了专业QA团队优势的教育，我们也将从开发团队中的QA中受益。
我们每周开会一次：我们分享成果，发现并计划在质量上共同努力。我们还每周分配几个空位用于公会任务。例如，我们正在完成发行人助理机器人。
义务...该行会部分涵盖了缺乏质量所有者和自动测试的问题。但是行会在开发和自动化方面没有很强的能力，因此我们的首席技术官做出了坚定的决定，并组织了工作。
现在，开发人员可以系统地改进管道流程：稳定，发现延迟发行的问题并进行修复。开发团队的一名开发人员成为管道所有者一个月，并对其进行系统地改进。不是发布而是改进-它使发布和支持测试的过程变得轻松而轻松。既然产品指标已得到改善，我们已经摆脱了这个服务员，但是我们可以随时返回。 （虽然写了一篇文章，我们还给它，因为通知开始下降稳定性）
课程...我们通过为手动测试人员开设课程来解决能力不足的问题，并与具有自动化经验的开发人员结对工作。
开发人员的额外工作。您无能为力，开发人员才刚刚进入接受自动测试的阶段。现在，如果较低级的测试无法覆盖某个功能，他们可以自己编写E2E测试，并且可以稳定管道。正如他们在智能书中所说的那样，当整个团队以及开发人员和测试人员可以编写测试时，这是一个好习惯。这也影响了我们从整体中前往饮用微服务的一面。整体中的测试更少，而在单独的存储库中的测试越来越多，管道变得更加稳定。
我们调查产品... 我们通过开始调查产品与预期行为的不一致之处来解决生产中的错误问题。我们安排了每周一次的探索性测试。并且，我们将错误提交给积压产品所有者。
我们现在该怎么办？
不考虑二阶和三阶后果导致了错误的决策。当第一个而非最佳选择强化了已经存在的偏见时，这尤其危险。但是现在，有了所有的经验，我们将采取不同的行动。
例如，能力丧失可以通过要求他们与具有自动化能力的人员过渡前几个月与产品中的所有QA工程师或团队中的开发人员共享能力来解决。一次就更好了。没有办法弥补开发人员额外工作的
问题，但是您可以通过不将测试放在事实之前来减轻编写测试的痛苦，但是：
- 明确显示测试的价值；
- 教开发人员编写，改进和维护这些测试；
- ( ), .
当我们采取不同的方式时，我们甚至都没有想到这些问题。 “事后看来”，考虑如何，这似乎是基本的。但是事后看来，我们都很坚强-尝试预测未来。
对于我来说，二阶或三阶后果可能是经验丰富的人的一阶后果，这些人多次做出这样的决定并看到了这样的决定的结果。
太多不确定性和变量会影响结果。
重要的是不要预测后果，但至少要知道后果可能是什么。在做出任何决定之前，重要的是要考虑可能产生的后果，阅读有关其他公司案件的信息，以便至少对可能的非显而易见的后果的规模有所了解。
任何学会预测任何决定的第二（甚至第三）后果的人都将能够拯救或摧毁人类。或者比Scrooge McDuck赚更多的钱-至少是从股价波动中赚钱的。
我现在该如何尝试预测后果
根据作者的说法，我阅读了有关该主题的文章，并为自己推导出了一些规则，这些规则将有助于预测此类后果。我将尝试使用它们：
- 在做出决定之前-问自己一个问题：“接下来会发生什么？” 并为问题添加时间表。10分钟，10个月或10年后会发生什么？
- 通过思考不同的情况来训练您对此类后果的思考。例如，如果整个世界都转向电动汽车，或者例如引入基本的无条件收入，那么一阶二阶甚至三阶的后果是什么。本练习中没有正确的答案，但可以使您进行更广泛的思考。
- 请记住，您脑海中的第一个念头就是第一顺序。总是。
如果在更改测试团队或其他团队的组织时遇到其他问题，请在评论中写下，这将很有趣，知道您面临的问题以及如何解决这些问题。
P.S. 2 QA- « » . . : , , SRE- mobile SRE . . , : (@EvgenSkt) HR (@alexpanev).
, , , : « » « » ( «» — ). QA, « ? ».
-, .