我在
Miro担任质量检查工程师。 我将向您介绍我们的实验，该实验将部分测试任务转移给开发人员，并将测试人员的角色转换为QA（质量保证）的角色。
首先，简要介绍我们的开发过程。 我们每天都有客户端版本，每周有3到5个服务器版本。 开发团队有60多人，分为10个职能Scrum团队。
我在集成团队中工作，该团队的任务是将我们的服务集成到外部产品中，并将外部产品集成到我们的服务中。 例如，我们
集成了Jira任务跟踪器 。 Jira卡-可视化显示的任务，您无需进入Jira即可方便地在板上进行工作。
实验是如何开始的？
这一切都始于一个普遍存在的问题。 当其中一名测试人员进入病历时，该团队的表现大大降低了。 团队继续处理任务，但是代码到达了测试阶段，任务暂停了。 结果，新功能无法按时投入生产。
测试人员假期休假是另一回事。 他需要事先找到一位愿意承担自己任务的测试人员，并同意自己沉浸在任务中。 两名测试人员同时休假是一种不允许的奢侈。
我们开始考虑如何解决问题，并意识到真正的问题是开发过程的狭窄瓶颈正在测试。 我将向您展示几个故事的示例。
第一个故事：无尽的任务回滚
还有一个开发商。 每个人都有自己的任务。 开发人员完成了其中一项任务，并将其交给我进行测试。 由于此任务的优先级比我当前的任务高，因此我切换到该任务。 我发现了错误，在Jira中获得了所有内容，并将其返回给开发人员进行修订。
我回到不得不推迟的任务。 开发人员从新任务切换到我返回的任务。 他更正了错误，并将我送回进行测试。 我再次发现错误，然后再次返回任务。 此过程可以持续很长时间。
结果，完成该任务的总时间增加了几倍，随后又增加了上市时间，这对于我们作为食品公司而言至关重要。 增加花在任务上的时间有几个原因：
- 任务在开发和测试之间不断转换。
- 任务空闲，等待测试人员或开发人员。
- 开发人员和测试人员必须定期在任务之间切换，这需要额外的时间和精力。
第二个故事：越来越多的任务
我们的Scrum团队有几个开发人员。 他们定期将任务提交给我进行测试。 我根据优先级执行一系列任务表格。
因此，我们工作了大约一年，但在此期间，公司发展迅速：项目和开发人员的数量增加了，因此测试任务的数量也增加了。 同时，我仍然是我们团队中唯一的测试人员，无法提高自己的速度。 结果，越来越多的任务堆积在测试队列中，并且在开发人员和测试人员之间转移任务的过程增加了等待时间。
突然我生病了。 我们的生产团队已停止提供新功能。 在这种情况下，团队应该做什么？ 您可以向测试人员寻求其他团队的帮助。 但是，很有可能他不会沉迷于我们的细节，这会对两支球队的素质和时间产生负面影响。
这两个故事的结论是相同的-团队过于依赖测试人员：
- 整个团队的表现受到测试人员表现的限制。
- 如果不增加测试人员，就无法增加开发人员的数量。
- 如果所有任务都进入测试队列，那么提高开发速度就没有意义。
- 在测试人员检查开发人员的工作的同时，降低了开发人员对质量的责任感。
- 如果没有测试器，则输出新功能的过程将受到影响。
让我们增加测试人员吗？
最明显的想法是增加测试人员。 这将起作用，但仅在一定程度上起作用：任务数量将不断增长，并且不可能无限地增加测试人员的数量-在某些时候它将变得昂贵且效率低下。 Dodo Pizza的首席执行官
Fedor Ovchinnikov在“资源思考”问题（您不能解决问题吗？请其他员工）上
写得很好 。
在现有资源范围内保持开发的速度和质量要高效得多。 因此，我们决定启动一项实验，该实验将考虑所有风险和边界情况，帮助团队立即创建功能。 他们称其为将测试人员转换为质量检查人员，因为它涉及团队中一个角色的转变：从猴子测试人员（确定开发人员的错误）到质量检查人员，后者有意识地确保开发过程各个阶段的质量。
让我们改善开发流程
实验目的：
- 消除团队对测试人员的依赖，但又不损失质量和时间。
- 团队中质量检查工程师提高质量保证。
第一步是改变团队的想法。 每个人都习惯于测试人员对团队的质量负责。
我们的假设是，增加准备和测试任务的时间将有助于减少处理一项任务的迭代次数。 反过来，这将允许在不损失速度和质量级别的情况下，将新功能引入生产环境，并且可能更快，质量更好。
我们与团队以及其他团队的测试人员一起制定了新的工作计划。 在团队进行工作的半年中，我们考虑了过程中出现的困难和问题，今天看起来像这样：
- 产品展示。
- 技术解决方案和测试方案。
- 开发和验证。
- 放行
问题陈述
产品负责人向团队提出问题的陈述。 该团队分析了配方，以便从技术和产品方面确定临界情况。 如果有问题需要进一步调查-设置一个单独的任务，为此在sprint中分配时间。
技术方案
问题表述的分析结果是一种技术解决方案，它是一个或多个开发人员。 公司的所有相关员工，包括质量检查人员，必须熟悉并同意该技术解决方案。 技术解决方案描述了我们正在解决的问题，将受到影响的产品功能块以及提议的更改代码的计划。
该解决方案使您可以根据相关参与者在开发过程中的经验，确定一个更简单，更好的解决方案。 手头有详细的技术说明-更容易发现和避免阻塞问题，更易于进行代码审查。
这是技术解决方案的一些示例：
任务说明
是否向系统添加了新的实体或方法？
如果是这样，将对它们进行描述和解释，为什么不可能在现有方法的框架内解决问题。
服务器交互是否在集群内改变？ 是否添加了新的群集角色？
数据模型在改变吗？
对于服务器，我们正在谈论对象和模型。
如果数据模型很复杂，则可以将其以UML图的形式或以文本描述的形式呈现。
客户端和服务器之间的交互是否正在改变？
更改说明。 如果这是API，可以将其提供给外部用户吗？ 不要忘记错误处理-即 指出正确的原因。
测试场景
与此同时，开发人员或质量保证人员拟定了一个测试方案，该方案考虑了发生问题的所有可能位置。 如果开发人员这样做，他将必须将该脚本提供给质量检查人员，然后对其进行完整性和充分性检查。 如果脚本是质量检查脚本，则开发人员必须确认他了解如何完成其每个项目。 团队还评估脚本的正确性。
对于脚本的编译和存储，我们使用HipTest。
开发与验证
开发人员开始根据技术解决方案并考虑测试文档中描述的所有可能情况来编写代码。 通过代码审查，并根据测试方案检查代码。 在母版中产生合并。
在此阶段，质量检查为开发人员提供了必要的支持。 例如，它有助于处理复杂的案例，设置测试环境，进行负载测试，并建议将大型功能输出到生产中的细微差别。
发布现成的功能
这是最后阶段。 在这里，可能需要团队预先\发布后的操作，例如，为beta用户提供新功能。
文档和工具
新的工作计划要求开发人员更加沉浸在测试过程中。 因此，作为QA，对我而言，为他们提供所有必要的工具并教授功能测试的基础知识很重要。 我们与其他团队的质量检查人员一起，列出了必要的文档，创建了遗漏的测试说明，并根据对开发人员不明显的内容，对现有的说明进行了最终确定。
然后，我们使开发人员可以使用所有测试工具和测试环境，并开始进行联合测试。 起初，开发人员不想对测试结果负责，因为没有人为他们检查任何东西，这对他们来说是不寻常的。 每个开发人员只有一个测试脚本，他开发的功能和“合并”按钮。 但是渐渐地他们习惯了。
实验结果
自实验开始以来已经过去了六个月。 该图显示了我们团队中每周的错误数量统计信息。 红色表示团队发现的所有错误的数目，绿色表示已修复的错误的数目。
可以看出，红线的电平保持在相同的电平，除了实验开始时的爆发。 没有更多的错误，这意味着我们保持了当前的质量水平。
同时，完成任务的平均时间仅减少了2％：实验开始前为12小时40分钟，之后为12小时25分钟。 因此，我们能够保持当前完成任务的速度。
因此，我们的团队不再高度依赖质量检查。 如果我生病或休假-团队将继续工作而不会降低速度和质量。
尽管时间和质量指标保持不变，我们是否认为实验成功？ 是的，我们相信，因为我们保持了工作的速度和质量，并腾出了质量检查时间，可以更加有意识地从事产品质量和开发流程的工作。 例如，要进行研究测试，请扩大功能测试的范围，并描述所有团队中开发测试文档的原则和规则。
在其他团队中，我们播下了实验的种子。 例如，在其中一个命令中，QA现在不测试开发人员在请求请求中描述的内容，因为开发人员可以自己查看它。 在另一个团队中，质量检查人员将分析请求更改，并仅检查复杂和非显而易见的情况。
开始实验前要记住的事情
这是一个复杂而漫长的实验。 只需单击一下即可实现，您需要仔细准备，而不要等待快速的结果。
为团队的消极做好准备。 您不能只说现在开发人员正在测试功能。 有必要为此做准备，开发方法，为团队和产品说明实验的价值。
开始时速度的损失是不可避免的。 需要时间来培训开发人员，编写缺少的文档以及进行重建过程需要花费时间，而这些都必须捐赠给实验。
没有现成的解决方案。 例如，
在Atlassian中实现了类似的过程，但这并不意味着您也可以按自己的方式实现它们。 适应公司文化和团队特点很重要。