免责声明：这是文章的翻译。 版权属于原创文章的作者和Miro公司。
我是Miro的质量检查工程师。 让我介绍一下我们的实验，该实验将部分测试任务转移给开发人员，并将测试工程师角色转换为QA（质量保证）。
首先简要介绍一下我们的开发过程。 我们有客户端的每日发行版和服务器端的3至5个每周发行版。 团队有60多个人，随即加入了10个功能Scrum团队。
我正在集成团队中工作。 我们的任务是：
- 将我们的服务整合到外部产品中
- 将外部产品集成到我们的服务中
例如，我们集成了Jira 。 Jira Cards-任务的可视化表示，因此使用完全不打开Jira的任务很有用。
实验如何开始
一切始于琐碎的问题。 当测试工程师某人请病假时，团队绩效将大大下降。 团队继续从事任务。 但是，当到达代码时，测试阶段的任务将继续。 结果，新功能无法及时投入生产。
测试工程师去度假是一个更复杂的故事。 他/她需要找到另一位测试工程师，他愿意承担额外的任务并进行知识共享。 在同一个时间由两名测试工程师去度假并不是一种奢望。
我们已经开始考虑如何解决这个问题。 我们发现根本原因是测试阶段是瓶颈。 让我分享一些例子。
情况1：任务乒乓球
有我和开发人员。 每个人都有自己的任务。 开发人员已完成一项任务，并将其发送给我进行测试。 至于此新任务具有更高的优先级，我将其打开。 我发现了缺陷，在Jira中提出了缺陷，然后将任务返还给开发人员进行修复。
我切换回先前的任务。 开发人员从当前任务切换回返回的任务。 修复后，开发人员将任务退还给我进行重新测试。 我再次发现缺陷，然后再次返回任务。 这可能会持续很长时间。
结果，在任务上花费的时间越来越少，因此上市时间对于我们作为产品公司而言至关重要。 增加努力的原因很少：
- 任务在测试工程师和开发人员之间不断移动
- 花费时间等待测试工程师或开发人员
- 开发人员和测试工程师必须经常在任务之间切换上下文，这会导致时间和精神上的额外损失。
情况2：任务队列增加
我们的Scrum团队中有一些开发人员。 他们定期发送任务给我进行测试。 这就形成了一个任务队列，我根据优先级进行处理。
这就是我们工作大约一年的方式。 但是在这段时间里公司成长了。 项目和开发人员的数量增加了，因此测试任务的数量也增加了。 同时，我仍然是Scrum团队中唯一的一名测试工程师，而且我无法及时提高性能。 结果，越来越多的任务排队等待测试和乒乓球处理，这也增加了等待时间。
突然我生病了。 从我们的Scrum团队到生产的新功能交付已完全停止。
在这种情况下应该做什么团队？ 可能需要其他团队的测试工程师帮助。 但是，另一位测试工程师不在上下文中，也没有提前获得知识转移，这将对两个团队的质量和进度产生负面影响。
两种情况的结果相同-团队也取决于测试工程师：
- 团队的速度受到测试工程师速度的限制。
- 不增加测试工程师就无法增加开发人员的数量，因为如果所有已开发的任务都排在测试队列中，那么加快开发速度就没有意义。
- 当测试工程师在开发人员之后验证任务时，开发人员对质量责任的减少正在减少。
- 如果测试工程师不可用，则交付过程受到影响。
让我们添加测试工程师吗？
显而易见的想法-让我们增加测试工程师的数量。 这可能会持续到某个时刻：任务数量会增加，但不可能不断增加测试工程师的数量。 这将太昂贵且效率低下。
更有效率的是保持当前资源的速度和质量。 因此，我们决定启动一项实验，以帮助团队在承担风险和极端情况的情况下创建具有嵌入式质量的功能。 我们将此实验称为“将测试人员转换为质量检查人员”，因为它是将一个角色从寻求bug的猴子测试人员转变为有意识地影响并在所有SDLC阶段提供质量的质量检查人员。
让我们改善开发流程
实验目标：
- 消除团队对测试工程师的依赖性，而不会失去质量和时间。
- 提高质量保证和团队提供的质量保证水平。
第一步是改变团队的观念。 所有人都期望测试工程师完全关心质量并对此负责。
我们的想法是在任务准备和验证中增加工作量将有助于减少乒乓迭代的次数。 因此，它将允许在生产中交付新功能，同时保持可接受的速度和质量水平，甚至可以改善这些水平。
我的Scrum团队与其他团队的测试工程师一起创建了新流程。 因此，我们已经为这个新流程进行了半年的工作，并且在此期间修复了一些问题，现在该流程看起来像：
- 陈述任务说明。
- 技术解决方案和测试方案。
- 开发和验证。
- 放行
任务说明
产品负责人向团队提出任务说明。 团队分析任务说明，从技术和产品的角度发现极端情况。 如果出现需要澄清或调查的问题，则将其作为单独的任务进行跟踪，并在冲刺中花费专用时间。
技术方案
作为分析的结果，是由一个或几个开发人员创建的技术解决方案。 所有相关的队友以及质量检查人员必须对此进行审查并达成一致。 技术解决方案包含解决方案的目的，将受影响的产品功能块以及计划中的代码更改的说明。
这种技术解决方案可以根据相关开发过程参与者的经验来发现更轻巧，更合适的解决方案。 有了详细的技术解决方案，就更容易发现和避免阻塞问题，更易于进行代码审查。
这是技术解决方案中一些块的示例：
任务说明
系统中是否引入了新的实体或方法？
如果是的话，将对这些内容进行说明，并说明为什么用当前方法无法解决任务。
集群中服务器的交互是否正在改变？ 是否引入了新的群集角色？
数据模型在改变吗？
对于服务器，它与对象和模型有关。
如果数据模型很复杂，则可以用UML图或文本描述表示。
客户端-服务器交互是否正在改变？
更改描述。 如果是API，那么我们可以发布它吗？ 不要忘记处理异常，即记录正确的原因。
测试场景
并行地，开发人员或质量保证人员在假设极端情况和潜在问题点的情况下创建测试方案。 如果是开发人员创建的，则质量检查人员必须对其完整性进行审查。 如果测试方案是由质量检查人员创建的，则开发人员需要检查并确认是否清楚实现每个要点。 团队还将评估测试方案的正确性。
为了创建和保留测试方案，我们使用了HipTest。
开发与验证
开发人员基于技术解决方案并假设极端情况和测试场景来创建应用程序代码。 通过测试场景的代码审查和验证功能。 将分支合并到主。
在此阶段，质量检查支持开发人员。 例如，帮助重现复杂的测试用例，测试环境配置，执行负载测试，咨询在生产中交付重要功能的咨询。
释放已完成的功能
这是最后阶段。 在这里，团队可能需要提供发布前和发布后的操作。 例如，为Beta用户启用新功能。
开发人员需要新的开发流程来更深入地测试它。
因此，重要的是，我作为质量检查人员，为他们提供了所有必要的工具，并研究了功能测试基础知识。 我们与其他团队的质量保证人员一起编制了必要文档的清单，创建了缺少的测试说明，并更新了现有的内容，包括对开发人员而言不明显的内容。
然后，我们授予开发人员访问所有测试工具和测试环境的权限，并开始一起执行测试。 起初，开发人员不想对测试结果负责，因为没有人在他们之后进行验证。 这很不寻常。 每个开发人员只有测试场景，该功能由“开发人员”和“合并”按钮创建。 但是他们很快适应了。
实验结果
自实验开始以来已经半年了。 每周有一个错误数量图表。 红色表示所有发现的错误的数量。 固定的错误数量以绿色表示。 黄线是实验的开始。
可以看到，除了实验开始时的派克，红线保持在相同的水平上。
错误的数量没有增加，因此我们保持了当前的质量水平。
与之相比，平均花费在任务上的时间减少了2％：实验前和实验前分别为12小时40分钟和 12小时25分钟后。 这意味着我们设法保持了速度。
结果，团队中不再存在来自QA的严格依赖。 如果我生病或要去度假，团队将继续发展而不会降低速度和质量。
尽管速度和质量保持不变，我们是否认为实验成功？ 是的，我们这样做是因为与此同时，我们释放了质量保证能力，可以有意识地从事产品和质量保证策略方面的工作。 例如，对于探索性测试，增加功能测试的覆盖范围以及描述所有团队中测试文档创建的原则和规则。
我们在其他团队中也有种子实验的心态。 例如，在一个小组中，质量检查人员现在不测试开发人员在提取请求中描述的内容，因为开发人员可以自己对其进行验证。 在另一个小组质量检查小组中，审核拉动请求并仅测试复杂且不明显的极端情况。
启动实验前应注意的事项
这是一个复杂而漫长的过程。 它无法立即实现。 这需要准备和耐心。 它不能保证快速获胜。
为团队的抵抗做好准备。 这并不是说从现在开始开发人员将验证功能的一种方法。 为他们准备这种精巧的方法，描述团队和产品的实验优势非常重要。
刚开始时速度损失是不可避免的。 开发人员进行知识转移，创建缺少的文档以及更改流程的时间，这是一项投资。
没有灵丹妙药例如，在Atlassian中正在实施类似的流程，但这并不意味着有可能在您的公司中实施它。根据公司的文化和具体情况调整实验很重要。