与Kontur的测试人员和分析师Andrei Marchenko和Marina Tretyakova七月文章的作者见面。 这个月，他们将讨论用于测试分析的工作流模型，以及他们如何在开发阶段之前开始测试分析。 这些经验对那些不在初创公司中居住并且对于质量比速度更重要的中型产品团队的经理，测试人员和分析师很有用。
Analytics（分析）测试工作流模型
模型1
在完成任务后，测试人员可以使用分析功能。 他通过阅读分析作为开发人员所做工作的文档来验证任务。 无论专业水平如何，一切都错了。 缺陷可能存在于分析中，也可能存在于开发人员代码中。
缺点：
- 在测试阶段之前不会检测到分析缺陷，
- 测试中的任务可能会回到分析中进行修订。 结果，TimeToMarket任务显着增加。
在测试过程中发现的分析错误既昂贵又非常昂贵。
优点：
- 减少了不需要分析师的任务（基础架构，重构）的测试人员的时间。
模型2
测试人员甚至在转移到开发之前就已连接到任务。 他查看任务的原型，或者只是阅读文档。 测试人员向分析师询问有关任务的所有问题。 分析人员立即纠正这些评论。 测试人员进行验收测试。
缺点：
- 测试人员必须研究相邻领域（设计分析和传统知识），
- 切换到此模型，测试人员将首先不得不花费更多的时间进行测试，因为过程``完成的任务已到达-我正在读取分析-我正在测试''延伸到``未来任务的描述已到达-我正在读取分析-我正在测试分析-已完成的任务已经到达-我正在测试''。
优点：
- 任务转移到开发后发现分析错误的可能性变小
- 测试人员已经在任务的上下文中，当它到达他进行测试时，因此他可以更快地检查它，
- 测试分析完美地拓展了视野，为专家提供了未来过渡到分析的机会，
- 开发人员提高了代码和整个产品的质量，因为在通过测试解决方案之前，他会通过验收测试。
如果开发团队没有对分析师的工作进行审查，则测试分析可以提高产品质量，并降低由于ToR中的错误而将任务转移到开发中的风险。
当我们向使用第一个模型的测试人员推荐第二个模型时，我们经常听到：
- “我们排队，因此有足够的当前任务来承担更多任务。”
- “与经理交谈。”
重新设计开发过程是一项严肃的管理任务。
在开发之前实施分析测试
与Kontur项目一样，在将近一年的时间里，开发过程中的标准是强制性的“分析测试”阶段。 团队没有立即解决这个问题。 推动力是从测试到分析和进一步完善阶段的任务回报数量增加。
对于具有新功能的大型任务而言，这尤其痛苦。 转移到测试阶段的前端任务是原始的，通常在最简单的场景下就无法完成，并且鉴于分析中定义和术语的“双重性”而以不同的方式实施。
只需按一下手指或任何一种魔术，分析测试过程就不会出现。 这是艰苦的工作，但可以分为多个阶段。
阶段0。向团队推销测试分析的想法
当您突然从工作中收到带有评论，建议和更正的反馈时，您可以轻松想象一种情况。 任何普通人的第一个念头都是：“你为什么决定测试我？ 他们不相信我吗？ 他们监视我的工作质量吗？” 在此阶段，非常重要的一点是，分析人员不要感到自己正在接受质量检查，如果测试失败，他们将被解雇。
如果密钥中包含该信息，则可以消除许多问题：“这将使我们有机会更早地了解新功能，加快测试阶段，并防止在代码中引入甚至很小的缺陷。”
阶段0完成后，您可以继续。
阶段1.在开发过程中实施分析测试
在说服团队之后，我们开始将分析测试引入日常工作流程中。 如果最初的工作流程如下所示：
实施后：
如果您的团队中有几个分析师，他们在进行开发任务之前互相进行了审查，那么我们将继续测试更好的文本。 我们的意思是说，分析审查不是对它进行测试，而只是对其的一部分。
阶段2.测试分析
原型取代分析的文本版本时，会有一些任务。
在这种情况下，原型也会作为文本进行检查。 如果原型补充了分析功能，则在阅读文档之前，请先查看将来功能的设计布局，这很有用。 这是您唯一的机会，以尚未阅读TOR且不知道一切如何工作以及应该如何工作的用户的身份看待任务。
可以在分析中检查的内容：
1.提出的解决方案符合任务的目标。
例如，如果任务的目标是收集用户的反馈，则解决方案应包括记录和存储用户响应。
2.解释的唯一性。
例如，措词“当天的显示信息”可以被不同地解释。 您可以了解如何“显示在设置中选择的日期的信息”，或作为“显示今天等于当天的信息”的方式。
3.决定的可行性。
可行性是在开发环境，编程语言和算法复杂性的众所周知限制下，实现以分析形式编写的需求的能力。 好的分析人员可以牢记可以解决所写问题的算法。 开发人员不会根据此算法进行操作（他们更加有知识，他们会找到使算法达到最佳状态的方法，等等），这不是事实，但是它的存在表明了该任务的可行性。
4，可测试性
目前尚不清楚如何验证是否满足“改善搜索结果”的条件。 但是，如果我们重写条件“搜索结果应在按下控件“搜索”后的1秒钟内显示给用户-这很明显。
5.替代方案的可用性。
在“如果显示了数字和日期，那么我们将打印数字和日期。 如果未指定日期，则仅打印数字“没有足够的脚本：
6.异常处理。
在措辞“您只能下载Excel格式的文档”中，不清楚如果我们上传其他格式的文件会发生什么，以及下载它们时会看到什么错误。
测试分析时的工件
测试分析后可能会保留哪些工件：
开发人员的清单-对应该进行测试的主要方案的必要，全面，基本的检查。 它也是提高代码质量的工具。 在提交测试任务之前，开发人员会通过检查清单，自己快速找出错误。
必须说服开发人员通过测试人员的检查表，消除开发人员“自己测试我”的内心烦恼，重点是“加快过程，加快测试，提高质量”。 结果，我们的开发人员仔细检查了这些清单，并为发现错误的不是测试人员，而是他自己（“没人会知道我在这种胡扯的情况下弄糟了什么”）。
结果如何
乍一看，在开发过程中引入新阶段似乎只会增加TimeToMarket，但这是一种幻想。 当然，起初，分析测试流程将是新的且未经测试，测试人员将花费更多时间。 将来，他将获得经验，将能够更快地进行操作。 而且，在测试分析阶段获得的结果将减少直接测试阶段的时间，并将收益数量降至最低。
此分析测试过程已在多个Contour团队中实施。 开发团队拥有许多不可否认的优势：
- 节省了测试阶段的时间：测试设计和测试分析没有成本，因为一切都已经预先完成，
- 在发现关键错误之前，通过清单加快对开发人员的反馈，
- 所有感兴趣的各方都可以预先检查清单并添加一些检查（在测试阶段，此操作“费用更高”）。
我们相信，通过在项目中实施分析测试阶段，您将能够获得这些优势。
日历文章列表：
尝试不同的方法
合理的配对测试
反馈：如何发生
优化测试
看书
分析测试
测试人员必须抓住错误，阅读Caner并组织迁移。
加载服务
质量检查服务指标
测试安全
了解您的客户
积压