观看视频，阅读成绩单，并对评论中表达的问题发表意见。让我们一起弄清楚：存在还是不存在？
第一讨论
时间码0:
56-是否始终需要进行测试？
2:00-为什么要测试何时需要将功能尽快推向市场？
3:24-是否可以仅测试基本功能或应用程序的一部分？
5 :29-测试功能的标准
7:28-初创公司或外包公司应在什么时候停止发布功能并开始浪费时间进行测试
见面会立即从热议开始-进行了讨论。因此，我们将在在线讨论中介绍参与者：
- 速度团队（Avito）首席工程师Dmitry Voronin。
- Yuri Chechetkin，移动开发人员（Revolut）
- Dmitry Manko，Android开发人员（Citymobil）
- Nina Semkina，高级程序员（Yandex.Money）
- Vladimir Genovich，首席程序员（Yandex.Money）
- 测试员Dmitry Zhakov（Yandex.Money）
妮娜·塞姆基纳（Nina Semkina）：许多人说必须将测试引入项目中……但是每个人都知道它非常昂贵。花费开发人员时间和大量资源来覆盖测试的所有代码是非常昂贵的。是否总是必须进行测试？
德米特里·曼科（Dmitry Manko）：您要测试什么？
Nina Semkina： Android应用程序。我何时需要了解其中的100％需要测试？
德米特里·曼科（Dmitry Manko）：如果市场不希望出现任何功能，那么从开发角度或覆盖范围角度来看，可以简化测试或完全忽略测试。这完全取决于产品。如果我们要制造一个具有2个功能的计算器，那么我们很可能不止一次地经历了一系列测试用例。因此，可以省去测试，可以将应用程序更快地投放市场，并可以缩短产品上市时间。
Nina Semkina：我们总是有一个上市时间竞赛，市场总是需要很多功能，我们不能放慢它们的速度。特别是当涉及到一个需要立即发布到市场的刚刚起步的项目时，我们没有名字，我们正在与其他公司竞争。目前，我们在乎什么测试？我们需要为我们的应用程序提供功能并更快地将其淘汰，否则它们将在3周内淘汰。为什么要测试它们？
德米特里·沃罗宁（Dmitry Voronin）：实际上，某些时候的开发速度开始取决于测试范围。例如，如果一家企业在结构上绑定到一个主要屏幕，所有主要功能均在该屏幕上，并且在其中进行了很多次更改，那么即使没有大型“功能流水线”，也无需进行测试就可以更缓慢地开始移动。似乎一旦有信号表明您经常重新回归，即有理由考虑涂层有问题并且您没有采取反应性行为这一事实。例如，某些东西经常坏掉，这意味着该地方没有得到应有的测试。
Nina Semkina：我是否可以得出结论，您只需要不断测试基本功能，并将功能“一站式”连接即可。让这些单独的功能带有错误，但是也许它们存在于今天和明天，它们不会存在。我只能测试应用程序的一部分吗？
Dmitry Manko：我想说关键部件值得测试。从业务角度看，此产品重要。并且，如果存在带有错误的功能，则它们应位于单独的某个位置，并且不会影响某些共同点，因此最好使用远程切换将其关闭。并且，如果根据分析发现确实存在错误，并且用户在抱怨，那么请关闭此功能。
德米特里·沃罗宁（Dmitry Voronin）：Dima谈到了一个很好的话题，即测试不是开发人员拥有的唯一质量控制工具。您应该始终记住，除了单元测试和集成测试之外，还应该进行手动测试。还有一些方法可以推广和回滚您的更改。如果您具有所有这些工程实践，那么从原理上讲，如果速度可以从中受益，则可以忽略某些工具，而使用其他工具。但是总的来说，如果开发人员具有测试文化，它通常被认为是一种很好的形式-开发人员更舒适，更可靠地交付更改，以便他测试了必须执行的功能。在我们公司中，通常会留下这样的代码，您可以在其中轻松进行更改，并快速运行测试以了解您没有破坏已经发生的事情。
Nina Semkina：在聊天中，他们写道，您需要测试带来收入的因素。并且当测试成本低于无法正常工作的功能所可能造成的损失时。原则上，这是了解确切需要测试的好标准。您能说出其他标准来测试特定功能吗？
Dmitry Manko：可以使用分析来确定标准。例如，如果您修复了最常用的功能，则建议对其进行测试，以使用户尽可能少地遇到错误。如果错误很少出现，那么这是一个小问题。而且，如果该禁令出现在授权屏幕上，则可能并不重要，但仍然是每个人都会看到的错误。这已经是声誉风险。
德米特里·扎科夫（Dmitry Zhakov）：通常需要进行测试。我们一定不能忘记测试是对产品要求的验证。如果某项不符合要求，那么这就是问题，错误，问题。所有测试用例和测试都可以自动化，如果没有足够的时间，那么首先值得检查关键时刻，然后再检查其他所有内容。例如，如果您明天发布一个版本，而您的企业明天想要一个功能，那么您将检查最关键的功能。而且，如果您有足够的时间，您可以负担得起检查中小案件的费用。这是您的测试是手动还是自动的问题。无论是指标还是UI测试，都可以由机器人完全验证。
Nina Semkina：我们现在都代表拥有许多资源和机会的大公司发言。如果我们考虑时间和资源有限的小公司，初创公司的观点。我认为起初每个人都会牺牲测试。在什么时候可以理解，这是我们停止和停止滚动功能并花费资源进行测试的关键里程碑？
德米特里·曼科（Dmitry Manko）：我可以分享自己的观点，因为我来自外包公司。外包主要是关于在哪里销售工时的，那里的测试确实很昂贵。有时，它比开发功能本身要花费更多。当客户等待应用程序并“旁听”时，此类外包公司并不以测试着称。在我们的团队中，我们面临以下情况。该产品是酒吧菜单，其中促销用于大量案件（生日，2对1，学生等）。而且我们注意到，这种库存功能在一年中的每个月都在中断。然后，理想情况下，单元测试描述了所有情况。我们了解了一切的工作原理（大约有70个测试用例）。我们打败了这款产品，但是，当然不可能在任何地方都可以做到这一点。
Yuri Chechetkin：我在金融科技公司的大型公司（Yandex，Alfa-Bank，Revolut）工作的经验，这些漏洞的严重性超出了规模。话虽这么说，但我在一家初创公司中很有经验，即使在那里，测试也是绝对必要的。我认为这是否是一家初创公司都没有关系，因为开发人员必须对其代码负责，而测试可以保证此代码有效。开发人员主要是工程师，负责开发产品。因此，您需要编写测试不是因为需要，而是因为它们可以帮助您。如果这些是为演示而编写的测试，那么这可能会减慢开发速度。而且，如果您需要测试并且自己了解它，那么必须编写它们。如果开发人员编写了代码并且确信它无需测试就可以工作，那么这将是一种风险，这是他的选择。但我仍然认为开发人员不应冒险，应该掩盖自己，并用测试覆盖一切。
Nina Semkina：因此，我们决定需要以某种方式测试我们的代码，我们将更详细地分析该主题。我现在请弗拉基米尔·热诺维奇发言。
第二个讨论
时间码
0:09-如何在发布前从质量检查中移除回归负载？公司是否有提高应用程序稳定性的策略？
4 :25-在UI测试中使用模拟或假对象有意义吗？
8 :05-对用户进行测试：是否可以接受？
妮娜·塞姆基纳（Nina Semkina）：在报告过程中，我们在聊天中收到了一个问题，我希望他继续进行讨论。发布前如何从质量检查中消除回归负担？我们的演讲者在选择测试地点时会采用哪些做法？公司是否有提高应用程序稳定性和减轻QA专家负担的策略？
德米特里·扎科夫（Dmitry Zhakov）：我们的策略是测试所有内容。因为我们是最后一个领域，所以员工才是用户。因此，我们仅将这样的应用程序提供给客户端，该应用程序始终可在任何地方稳定运行。唯一的问题是速度。最初，手动运行花了我们很长时间-长达一周。但是由于自动化，我们实现了发布平均持续一天的时间。因此，如果您要开发任何功能，则需要同意您或测试人员将立即编写自动测试。某些无法自动执行的移动特定情况仅需在回归时进行检查，然后机器人会检查其余情况。因此，您将卸载测试人员，让他们从事更有趣的研究工作，并为机器人提供整个例程-单击脚本。
Yuri Chechetkin：大多数大公司拒绝进行质量检查和手动测试。这不完全是一条革命性的道路，而是过去的遗迹。而且，例如，在我现在工作的公司里，诸如回归这样的词甚至都没有发音。我们根本没有质量检查部门。
弗拉基米尔·吉诺维奇（Vladimir Genovich）：您可能会自动化？
尤里·切奇金（Yuri Chechetkin）：不完全是，他只是在项目的初始阶段，然后他就离开了。
Vladimir Genovich：您运行UI测试，对吗？
Yuri Chechetkin：当然，有UI测试。
Vladimir Genovich：单元测试？那么在发行时运行这些测试不是回归吗？
Yuri Chechetkin：是的，这是回归，但是没有我们习惯谈论的手动测试。这是一个非常有趣的方法。它使人清醒，并将开发人员从编写代码并将其提供给测试人员的“孩子”转变为负责他自己的代码的更加成熟和独立的工程师。至于视觉方面，可以由设计师或采购员进行审核。还有像截图测试之类的东西-如Facebook。因此，现在看来食品公司可以不用质量检查了。测试人员自己可以做更多有趣的工作。当然，外包中的情况略有不同-他们出售工时，而质量检查可以作为附加服务出售。
德米特里·扎科夫（Dmitry Zhakov）：事实证明，您拥有回归，将其简单地交给了自动化，并且您拥有从事应用程序研究工作的人员。测试不仅可以是UI，还可以是不同的。
Yuri Chechetkin：是的，例如，对用户进行测试。
妮娜·塞姆基纳（Nina Semkina）：在谈到这个非常危险的话题之前，我想听听听众的下一个问题。在UI测试中使用模拟或伪造的对象有意义吗？
德米特里·沃罗宁（Dmitry Voronin）：这是有道理的，没有他们就没有了。因为具有完全集成的UI测试非常不可靠。而且，您永远都不能依赖具有30个系统的测试，每个系统都存在运行请求请求的一系列故障点。这样的测试是不可行的。而且任何公司中都没有人能够使这种事情奏效。因此，UI测试是移动开发的祸根。如果可能的话，最好在没有UI的情况下进行测试。但是由于我们被迫使用框架，并且唯一的选择是某种机器人技术，而在iOS中，事实并非如此。为了检查与至少一个对我们重要的系统的交互，我们在设备上运行了所有程序。由于我们的开发尚不成熟，因此用户界面就在这里，我们希望捕获最大的用户界面以便检查用户的点击情况-我们非常镇定。在我看来，一段时间后，这将成为过去，我们将不再担心模拟，点击，也不会与系统争吵来检查应有的一切，因为我们无论如何都不会进行一切检查。可能存在任何用户界面测试都无法检查的视觉错误。因此，我相信可以并且应该在UI测试中进行模拟，其主要目的是提高该工具的稳定性，使其达到有用的状态。在这种情况下，真正的好处是确保没有回归。当我们停止信任时，任何刷新的工具都会变成弗拉基米尔·吉诺维奇上一次报告中的第二个“ D”。当大量随机值开始进入我们的测试时就会发生这种情况。这样的测试不会给人任何自信心，而只会给测试已经过测试的错误希望。
Dmitry Zhakov：我们的案例中约有70％是自动化的，并且在应用程序中没有使用任何模拟。将它们迁移到后端可能会更容易。例如，如果它指的是卡号，那么您会希望不要求您提供3DS。也就是说，应用程序不知道它已被锁定。我认为这是基础架构问题。
Nina Semkina：在继续提交下一份报告之前，我希望我们提到一个比较棘手的话题-用户测试。许多人为此犯罪：他们总是想要并注入……您对此有何看法？是否可以让您自己狡猾地向用户推广，从他们那里收集崩溃并为您自己修复。在对它们进行测试之后，推出完善的成熟版本。还是通常不可接受？还是有合理的界限？
Yuri Chechetkin：我们在Revolut进行一些练习，其意义并不在于直接参与战斗，而在于真正的用户。该演示还对用户进行了一些测试，并且在演示过程中出现了有关流程等问题。在这个阶段，可能会有关于设计和通用力学的问题。除其他事项外，还进行内部滚动-公司规模很大，有1000多人，我们可以在同事中进行扩展。这是用户测试，但不是外部测试，因此似乎很安全。然后可以将其推广到外部的一小部分实际用户，但是可以通过切换关闭此功能。您认为在这些阶段可能出什么问题？
德米特里·曼科（Dmitry Manko）：在我们的现实中，事情可能会出错。无论我们多么努力地完成这些阶段，在任何情况下，当我们需要监视崩溃分析时，情况都会发生跳跃。发布并不以我们将其发送到商店，所有阶段已经过去，一切都可以的事实结束。您需要继续观察应用程序的行为。
Yuri Chechetkin：绝对可以。在我们的案例中，我们为5％的用户提供了演示，内部部署和测试，而不是手动测试。当然，该功能发布后，您需要查看一下。滚动不应马上100％结束-这是主要的防御机制。
德米特里·沃罗宁（Dmitry Voronin）：Google为我们处理了用户测试的道德问题。苹果似乎没有。如您所知，有一些特殊的发行渠道（alpha，beta ...生产）。任何人都可以进入beta测试，并且他们同意一种易于理解的格式，该格式表示他们完全同意可能会收到该产品的不稳定版本。因此，他想自愿并帮助公司改善产品。一旦我们公开地告诉一个人，我认为这个问题应该被消除，并且我们不应该害怕在那里推出一个我们不能100％确定的版本。当我们从那里获得反馈时，甚至会更好，并且每次发布此类不稳定版本时，我们都会改进此过程。如果公司的流程可以跟踪Beta的质量趋势，那么情况只会变得更好。这对用户也是一个好处-他们将是第一个使用功能的人。这些人大多是您产品的积极忠实用户，他们自己将想要测试应用程序中出现的新事物。他们甚至准备为此牺牲一些。
妮娜·塞姆基纳（Nina Semkina）：我们了解，当我们谈论忠诚的受众时，只要不影响其个人利益，它就是忠诚的。这样，我们就可以推出带有其他小包子的功能，即使这些小包子掉下来，这些用户也不会感到非常沮丧。但是，即使此人确认他已准备好参加考试版本，但是他身上有严重的问题（例如，将注销额外的钱），那么他将不再忠诚。公司越大，用户对产品的反应就越苛刻。
弗拉基米尔·吉诺维奇（Vladimir Genovich）：但是，不管公司如何混乱，爱你的早期采用者又如何呢？而且，最有可能的是，这家公司将能够弥补损失。同意，如果我们推出新产品，我们会对用户说：“听着，我们很害怕。而且您可能会损失1000卢布。但是我们会偿还您的款项。”这样的用户很可能会自行承担风险，如果金钱损失了，我们以后就不会告诉他：“好吧，你自己应该承担责任。”因此，我认为，即使是银行应用程序，我们也可以为用户提供帮助。
德米特里·扎科夫（Dmitry Zhakov）：并且，如果您的Beta测试人员太少，则可以在配置文件的帮助下使用A / B测试来启用/禁用某些功能，这样在发生崩溃的情况下，您可以立即禁用某些功能并根据需要对其进行测试。我们记得，在移动设备中回滚是非常困难的，因此最好在发行前检查所有内容。
弗拉基米尔·吉诺维奇（Vladimir Genovich）：或用React Native编写））
妮娜·塞姆基纳（Nina Semkina）：由于下一次报告的时间到了，我将打断我们的谈话。迪玛，我请你发言。
第三讨论
时间码
0:05-如何改善回归测试？在功能开发中如何以及何时引入测试（Avito的经验）
10 : 43-单元测试在哪里进行追赶：在CI上还是在推送之前在本地进行？
Nina Semkina：我想联系Dima Voronin，以听取他的意见，以及他在公司如何改进回归测试以及在开发功能时引入测试的经验。
德米特里·沃罗宁（Dmitry Voronin）：我真的有东西要分享。这是处理手动回归的五年历史。这部分是我们对前两份报告之间问题的答案的延续。这个问题是关于如果您进行手动回归该怎么办。因为不是每个人都可以重复Revolut体验。这些家伙是很好的伙伴，他们从肩膀上砍下来，而且他们设法做到了可靠。这需要很大的勇气和良好的开发文化，最重要的是，要了解对这种方法不感到野蛮的开发主管。发生这种情况是因为我们的工作存在惯性，并且很难改变基础，尤其是在大型公司中。 Revolut示例证明，如果可行，那么它至少比手动回归要快，并且每个开发人员都开始向自己提出正确的问题。也就是说，他开始负责发布周期的大部分时间，即直到他提交更改的那一刻才开始负责，但是像任何成人工程师一样，他还在发布阶段负责产品。
我们怎么了当时我们需要5个人在12个工作日内完成手动回归，否则，移动应用将无法滚动。那是2015年。那时我们还没有一个自动化的UI测试。我们几乎从一开始就编写单元测试，并且写得相当积极。弗拉基米尔（Vladimir）在他的报告中谈到了10秒和1000次测试-让我难以想象的是，当我们在2014年通过这样的时刻时。现在我们有12,000个单元测试，它们不需要10秒钟，这也不是免费的。即使所有工程师都理解并编写测试，但还是有一个棘手的时刻。所有这些单元测试都不能证明生产中的错误以及应用程序的行为。也就是说，测试可以捕获行为，使其更容易进行更改并提供反馈，你做对了吗问题是有一个质量检查部门。当然，这不是问题。问题在于他们有一项任务是提供一定水平的质量。他们已经习惯了达到这一水平，承担了责任。如果这不是您产品的一开始，就很难改变这一时刻。有什么食谱？最正确的做法是，当我们解雇所有人并且一切都由自动化接管时，不要打开硬模式。这可能是我所见过的最恐怖，最不成熟的方法。怎么了首先，测试质量会损失一段时间。其次，所有进程都被销毁，新的进程无法快速构建。他们已经习惯了达到这一水平，承担了责任。如果这不是您产品的一开始，就很难改变这一时刻。有什么食谱？最正确的做法是，当我们解雇所有人并且一切都由自动化接管时，不要打开硬模式。这可能是我所见过的最恐怖，最不成熟的方法。怎么了首先，测试质量会损失一段时间。其次，所有进程都被销毁，新的进程无法快速构建。他们已经习惯了达到这一水平，承担了责任。如果这不是您产品的一开始，就很难改变这一时刻。有什么食谱？最正确的做法是，当我们解雇所有人并且一切都由自动化接管时，不要打开硬模式。这可能是我所见过的最恐怖，最不成熟的方法。怎么了首先，测试质量会损失一段时间。其次，所有进程都被销毁，新的进程无法快速构建。测试的质量会损失一段时间。其次，所有进程都被销毁，新的进程无法快速构建。测试的质量会损失一段时间。其次，所有进程都被销毁，新的进程无法快速构建。
我们做了什么？我们通过编写替代回归的UI测试开始了优化。也就是说，这些是成熟的基础架构测试，与测试用户接触到后端。而且，实际上，正如您所知，这项工作的结果是各种流行的框架-例如，Kaspresso。这正是我们开始时奠定的基础。我们留下了一堆可以帮助开发人员的工件。因此，现在更容易进行测试。我们还在开源中引入了各种跑步者，每个人都可以看到我们如何与他们合作。但是，我们并没有忘记手动测试，它的优化以及这两个部门如何开始合并为一个有效的过程。点B可能是革命状态。但是和许多其他公司一样，我们从A点到B点的道路，需要很长的时间。现在，我们处于QA扮演研究人员角色的阶段，他们将自己更多地投入到产品中，按照功能要求进行工作，编写自动测试。
关于改进手动回归的实践，最有趣的是影响分析。也就是说，尝试回答以下问题：“此版本中有哪些更改？”我们可以测试什么，我们可以放心地将其推广到下一阶段。影响分析是一个棘手的问题，因为当发布周期较长（即被释放2-3个月）时，影响分析将始终回答您相同的问题，因为在这段时间内，几乎没有涉及到应用程序的任何部分。但是，如果将发布周期缩短到一周，甚至更好的是一天，那么影响分析将显示出足够多的内容，并留下有助于优化手动回归的标记。我们已经非常成功地应用了这种做法。最初存在错误，但是我们一次减少了手动测试的数量。
下一步是优化测试模型。奇怪的是，但是在测试中也有一些遗留问题：编写了测试，但是测试可能不是很理想，然后在其中添加了其他内容，并且对此不进行测试用例的处理……通过详细的分析，结果可以减少很多次测试方案的数量。
这三个方向使我们可以达到每天将其发布到Beta的程度，每周一次达到100％的用户，因此无需进行手动回归。我希望这个故事会激发对发布状态不满意的公司采取行动-为了将来只按发布按钮，一切都交给用户，每个人都只看图表。
Yuri Chechetkin：当然，这些不仅是Revolut的做法，而且在全世界都是，它们被Google，Facebook等使用。我同意这应该是一个平稳的过渡。当许多人成为采购订单或进行自动质量检查时，一切都变得有些模糊，演变并变成了某种说法。但是在俄罗斯，这种趋势才刚刚开始。就像您正确说的那样，他应该尽可能健康。
Nina Semkina：有一个问题。谁在哪里进行单元测试？在CI之前还是在本地推送？
Yuri Chechetkin：本地驾驶似乎是开发人员的任务，也就是说，您不应强行执行。对我来说很明显，CI应该有100％。
Nina Semkina：感谢所有参与者的讨论！我请发言者发言Dima Manko和他的报告。