哈Ha 在上一届BackendConf会议上，我们的软件测试和质量控制部门负责人Anton Olievsky谈到了最重要的事情，也许是最重要的事情-有意识的工作态度。
就是这个 实施业务构想的速度已成为关键因素。 SJ中的此速度由完成任务所需的平均时间估算。 在公司中，此时间等于65天。 是的，从创建任务到将其发送给用户两个月。
安东说，由于有意识的测试，他们能够将流程加快3倍。 现在，我们将告诉您它是什么以及如何精确。
以前怎么样
过程是这样的：
如果结果成功，则将发布版本发送给用户，等待测试的50-60个任务一直挂在板上。
您如何完成任务：
- 从开发开始，任务就进入了测试阶段，并丢失在等待其他任务的无底洞中。
- 然后由测试人员检查任务，对其进行错误修复，然后将其发送回开发。
重复该循环，该任务可能会在测试阶段冻结几个月。 从技术角度来看，一切都很好，只有功能发布缓慢，并且业务不愉快。 测试人员不断地听到这样一个事实，即发展进展非常缓慢，截止日期已到，业务正在亏损。
像任何普通的测试人员一样，他们阅读有关测试的精明书籍，并认为最主要的是产品的质量。 就像，您需要找到尽可能多的错误，并确定将其全部修复。 但是没有
为什么不呢
因为我们不需要修复错误，而是需要帮助企业，所以安东去了产品Dima处理这种情况。 在那里，他们认为主要是功能发布的速度。 事实是，企业不喜欢在开发和修复项目上赔钱，目前尚不清楚是否会带来收益。 因此，最好发布一个不完善的项目，并根据其成功的结果来决定是使其达到理想状态还是将其最小化。 测试人员聚集在一起，试图了解如何提高发布速度。 事实证明，一切都是显而易见的。
SJ接受（一套用于检查产品整体功能的主要功能领域的案例，例如，用户授权，职位分配等），其中包括150个案例，耗时1.5天。 太长了
严重的是，这大约是每周2次1.5天的手动检查。 反复进行手动检查应怎么办？ 自动化。
事实证明，这可以使100个案例自动化。 关于自动化共享，发送信件，接收短信的无利可图的案例仍然无利可图。 测试人员很高兴，因为测试发布的常规成本更低-3小时而不是1.5天。 其次，自动测试可以快速反馈是否在任务进入发行版之前就开始观看发行版并捕获错误。
几乎所有事情都决定了，但是首席技术官来了。
还有什么问题吗？
他来了，说我们需要看看过量的工作时间还在哪里。 伙计们坐下来，意识到重复的动作只是针对发布-就是接受和整合。
整合呢？ 简而言之，在某些情况下，他们发送了发行版，而Dim的产品却发怒了，因为他们承诺的任务没有参加战斗。 他们开始弄清楚她去了哪里。 事实证明，将任务保持在发布分支中时，一些提交丢失了，并且该任务对于用户而言是视觉上丢失的。
Devops开始修复构建脚本，测试人员仔细检查了发行版中每个任务的用例，以确保所有内容结合在一起并且所有任务均已就绪。 检查已经完成的任务似乎很困难。 但是事实证明，该版本中的每个测试人员大约要执行5个任务，并且遇到了复杂的情况，例如更改数据库中的某些内容，运行脚本，检查收到的信件。 这整个阶段花费了大量时间：所有测试人员的工作时间为2到10个小时。
伙计们对这种实践进行了几个月的统计，结果发现没有更多的版本发布不佳的案例，并且在此阶段只有两次，在测试任务时遗漏了一些非关键的错误。 权衡了所有利弊，决定放弃这个阶段。
现在好吗？
不好 在IT世界中，您无法长期享受成功，因为总有一些需要改进的地方。 在我们的案例中，这些文件每周发布两次。 例如，测试人员在星期三早上检查了该任务并将其发送释放，并且仅在下周二才将其提供给用户。
还有什么 业务中的修补程序太多。 该公司原计划计划发布某个功能，然后宣布并发布了广告，测试人员是：“垃圾，同性恋，我们已经计划在此发布，任务将在下周推出。” 因此，对于每个这样的任务，产品Dima都会求助于他们。
每个人都知道，如果Dima进入开发阶段，那么就迫在眉睫。 这种突袭使开发人员和测试人员感到厌倦。 这不是再次去会议室的原因吗？ 他们都将自己锁定在一起，并决定业务需要更频繁地发布，因此您需要更多地自动化，在三个小时内检查发布，使发布的日常构建自动化，并在发布上配置自动测试的发布并每天进行验收。
这是一次小小的胜利，因为第二天测试了最大值之后，功能就会溢出。 修补程序的问题较少，一些问题已发送到当前版本，有些正在等待明天的版本。 这使测试人员不会因这些检查而分心，并腾出时间来测试新任务。 顺便说一下，遗漏错误的统计数据保持不变。
然后测试员朱莉娅来到安东，说她已经厌倦了。 就像做您想做的一样，但是她不能再每天接受一次，因为事实上，根据主要功能，很少有更改并且没有发现错误。 因此，朱莉娅提议每周进行一次接受。
好吧，同性恋。
怎么了？
节省时间-每周12个小时测试新任务，减少单调检查的动力。 缺点-自出现之日起，漏洞最多可以保留5天。 为了加速，已经做了很多成功的工作，但是与此同时，这些家伙对最重要的事情-完成生产任务所花费的平均时间几乎没有影响。
他们朝着目标前进，但没有实现。 是的，测试人员可以将时间投入到新任务上，但是对于通过速度而言，这简直是九牛一毛。
安东离开去思考要完成哪些任务，并意识到几乎所有事情。 而且像马里亚纳海沟（Mariana Trench）一样，河流很大，因此无法处理所有东西。 因此，决定优先考虑。 在此阶段，产品Dima提供了帮助，后者与Anton一起验证了对业务不重要的所有内容。
只有与用户的金钱和关键事物直接相关的要点仍然存在。
简而言之，在300个项目的列表中只剩下50个。
您已经可以使用此功能。 顺便说一下，网站开发能带来什么好处？
现在最重要的是。 是的，测试书籍教会您如何测试所有内容，但是所有情况都告诉安东，并非所有内容都需要测试。 根据安东的说法，这三天的反思让他感到像哈姆雷特（Hamlet）的问题：“成为还是不成为”。
他把所有的意志都化为拳头，他决定要成为什么样。 他拒绝测试不重要的功能。 开发人员在开发完成后立即开始在这250个点上投入任务。 说真的
并非每个公司都同意这样的步骤，几乎所有拒绝测试的测试人员都对谣言产生了伤害。 但是，这一决定使专注于真正重要的事情成为可能。
测试失败是一个负责任的危险步骤。
如果您还想这样做：- 关键功能列表是公开可用的，以便开发人员可以访问它。
- 要评估新方法，请向Jira添加“在=>生成中生成”的关系。 因此，您可以跟踪无法测试的任务中遇到了多少错误；
- 由于测试大多数任务并不是很愚蠢，因此请检查其中的几个主要案例，但要检查发布中的主要案例，以免减慢浇注的速度。
会有什么变化？- 重要的是要更快地进行测试，因为现在无关紧要的是不会对电路板造成干扰。
有什么不好- 由于缺少的错误开始来自用户，因此技术支持的负担正在增加。
疼吗
他们在六个月内完成了所有描述的步骤。 是的，很痛，但是输出如下：
完成一项任务所需的平均时间减少到19天，并且持续减少。
测试任务的流程减少了。 测试人员开始准备与开发同时进行的重要功能测试。
产品Dima完全停止前往安东。
而不是结论
请勿在药品或飞机制造中使用我们的方法。 在与生命危险无关的情况下-测试您的决策和方法。
不要仅仅因为书是写在某处就相信书并为了测试而停止测试。
问问自己自己是否满足企业的期望，以及待办事项清单上的每个项目是否真的有用。
SuperJob和你在一起。 对所有人的意识！