您好，哈布罗夫斯克市民！
我决定写一篇文章，介绍我们的测试人员和分析师之间的互动过程以及SuperJob公司从该过程中获得的奖金。
有需求的测试人员的工作包括三个阶段：《金融时报》审查，《金融时报》覆盖率，案例审查。
FT评论
需求由Enterprise Architect中的分析师维护，然后从那里复制到Confluence。 编写需求后，将其发送给测试人员进行审查。
尽管此互动是通过Google表格进行的，但存在以下情况：
- FT名称
- 连结至FT
- 负责《金融时报》分析师
- 分析师的状态
- 负责的测试员
- 测试人员的状态
分析人员在表的相应段落中将状态“正在审核”：
在此阶段，作为Confluence的一部分，会询问有关某些需求点的问题，因为该功能允许您在文本的任意部分添加注释。 在评论中，正在进行讨论，因此更新了《金融时报》。
在需求被添加和更新之后，它们被转移到开发和测试中。
金融时报报道
测试用例用TestRail编写；测试用例的存储架构完全重复了需求存储架构。 为了便于搜索，这是必需的，并且为了不重新发明您的自行车，从分析家邻居处更容易拿走它。
测试涵盖了需求-涵盖了每一项需求和每项报价。
每个需求项都有编号；对于需求项，有一些测试用例。 另外，我想指出的是，在每种情况下都有编写该案例的FT版本-需求可能会发生变化，并且其中的要点也会改变，如果您不考虑FT版本的话，那么您将找不到目的。
通过这种方式：
- 检查案件覆盖范围的质量很容易。 在我眼前，并没有50个案例和附近的FT表，而是您选择了一个要点，然后您看到哪些案例涵盖了这一点；
- 如果需求发生变化，您可以立即看到需要纠正的情况。
案例分为三种版本：
- 标题案例（大多数）。 当案件只有一个标题时，很清楚需要做什么。 与详细的测试用例相比，它们的编写速度更快，同时具有透明的覆盖范围：
- 测试用例。 一个详细的测试用例，其中包含很多细微差别的步骤，而这些细微差别都不能放在标题中；
- 案件，清单。 当案例包含用于检查功能某些方向的检查表时。 要突出显示这种情况，请在标题（大小写）中使用：
在《金融时报》的章节中，其中有实体模型，创建了测试用例“与布局M ...对帐”。 它只是在提醒您存在一个布局，必须用它来验证实现。 这种情况没有内部描述-与我们在法规中描述的布局相符的检查表。
个案审查
编写完案例后，状态为“案例复审”（Case Review）被置于总表中，这表明另一个测试人员可以接受该金融时报进行案例复审。 这是必要的，以便所有测试人员都清楚案例，并以崭新的眼光浏览要求。
例如，如果审核未成功通过，则《金融时报》上出现了新问题或覆盖范围不足-要求已转为“最终确定”状态。 TestRail中没有足够的注释来描述您的所有愿望-尽管这是用Slack编写的，这对于跟踪不是很方便。
如果审核成功，则FT处于“完成”状态。
在极少数情况下，当在需求上编写测试用例后对需求进行更新时，FT将转换为“已更新”状态。 此外，涵盖FT的测试人员还订阅了Confluence页面的更新。 如果需求发生了很大变化，那么将为测试人员创建一个任务以更新案例。
结论
是什么赋予我们这种方法？
- 首先，成熟的需求落入了开发之中。 这节省了开发人员的时间，而FT的不合理性，缺点和障碍根本无法实现。
- 其次，测试人员正在准备与开发并行进行测试，因此我们减少了发布功能所需的时间。 测试人员可以冷静且负责任地处理案例的编写过程，而不必采用以下格式：“啊，一个巨大的功能已经下降，您需要今晚将其倒下。 让我们测试更快！”
- 第三，由于案件复审，这提高了测试质量。 说“不！” 模糊的外观。
什么不喜欢？
- 在编写案例和在某个功能部件上运行它们之间存在相当大的时间间隔-尽管案例已经准备好并且只能进行检查，但是测试人员仍然脱离了上下文。
- 正如我之前所写-在TestRail中，没有足够的注释（如在Confluence中）-您不能只留下并标记问题所在，而是对其进行注释。
现在就这些了。 感谢您的关注！
以及如何满足您的需求？