阅读有关Web测试主题的文章，有条件地笼罩着两个主题：1）手动测试正在消失，自动测试（以下简称自动测试是Selenium UI和REST测试）已成为我们的一切； 2）自动测试不是万能的；手动测试是必不可少的。 同时，从文章来看，对软件质量和产品开发速度的要求有增加的趋势。 当这些要求很关键时，就是这种情况。
该产品已经有12年的历史了，但仍在积极发展。 部署每天进行一次，有时是两次。 因此，对我们而言至关重要的是，仅对自动测试进行回归。 但是，在Wrike（公司）中，有30多个Scrum团队，自动化团队的员工并不精疲力尽。 在这种情况下，最好不要期望手动场景的自动化，只能选择一个或两个冲刺。 我们公司的经验表明，手动测试器可以在某些细微差别下独立编写自动测试。 在文章中，我将介绍它们，以及我认为为什么这种能力不仅有助于跟上趋势，而且对测试人员本人也很有用。
标准流程
许多团队习惯于什么过程？ 视情况而定，但共同的特征大致相同。 有自动和手动测试部门。 手动测试器可以分布在Scrum命令中。 在这种情况下，自动化通常与特定团队无关。
使用新功能时，测试人员会创建测试脚本，他以预定的方式为自动化程序标记了其中的一些脚本。 另外，如果已经有进行调整的情况，则也将其记录下来以更新代码。 然后将标记的测试转移到自动化部门。 自动化工程师团队将负责在以下sprint之一中修复电流并编写新的自动测试。 除了对测试方案进行编程之外，自动化器的任务还包括运行自动测试，分析结果以及支持和开发测试项目。 事实证明，自动化部门充当外包执行者，而手动测试人员是一种客户。
客户还花费时间来编写详细而准确的TOR，定期讨论实施方法并选择必要的测试。 在没有自动测试的情况下，也存在可能会跳过错误的风险。 不要忘记，只有自动测试才能解决其中的一层技术问题，这样可以节省大量时间。 此类任务必须在仍然缺少自动化的部分中手动检查。
承包商并没有完全沉浸于团队所从事的功能中，将需要时间将自己肤浅地投入到任务和TOR的意识中。 同时，测试很可能没有准确地转换为代码，因此它不会检查我们想要的内容。 因此，降低了测试基础的效率。
自动化团队是测试项目的唯一贡献者，可以完全控制其代码库，从而可以轻松地在任何方向进行开发。 但是，由于来自其他团队的负荷增加，因此时间不足。 可以通过增加人员来解决问题，但是自动化的成本将超过其有效性。 即使您除去一部分负载，也给手动测试人员提供了运行测试并分析掉落的测试的机会，但这也无法带来正确的结果。 由于他们没有用于调试测试的工具，因此他们可能不了解由于xpath的更改等导致测试崩溃。
因此，在输出中，我们得到这种方案的自动测试跟不上产品的增长，这导致代码覆盖率很差。 由于对TK的解释不正确，测试可能会跳过错误。 如果长时间不合时宜，落下的零件不会立即得到修复，因此手动测试人员很难立即判断出系统的哪个部分已完全覆盖自动化。 自动测试成为某种黑匣子，测试人员对此不信任。 因此，从长远来看，不必要的手动检查的数量在增加，任务的条件被延长，并且质量下降。
您可以解决这些缺点，但是产品和公司越大，流程中的参与者就越痛苦，最重要的是，很难顺应增长速度和提高质量的趋势。 测试员本人会成为常规的人质，并且实际上并不会停留在时间上。
破坏方式
因此，它如何以我所工作的团队为例。 有自动和手动测试团队。 初始数据仍然相似，但是随后开始出现差异。 手动测试人员分布在其Scrum团队中。 每个Scrum团队都有自己的自动测试仪。 如果负载允许，有时可以将其分配给一个团队而不是两个。
使用新功能时，测试人员会编写检查清单，然后根据检查清单进行手动检查。 此清单中测试的最低要求部分是自动的。 在功能正在开发或测试中时，测试人员自己编写这些自动测试。 此外，将书面代码提供给审阅者进行审阅。 除极少数情况外，无法发出没有自动测试的任务。
当然，Wrike中没有要求由手动测试人员编写自动测试的要求。 这仍由团队自行决定。 您可以将一切交给自动化。 您可以将自己限制为通过类比来修复损坏的和/或编写新的测试，并将更复杂的任务（创建新的测试或扩展旧的后端句柄，Page Object或测试步骤和类）委派给专用的自动化工具。 这一切都取决于您，但是却错过了独立编写自动测试所带来的优势，这是愚蠢的。
我们的整个回归基于自动测试，而手动测试人员的职责包括运行和分析自动测试失败。 对于团队正在研究的每个分支，他们都会进行自动测试，作为质量的最初和最终保证。 因此，对于编写自动测试的人来说，更容易理解为什么在其分支上运行的测试崩溃了。 有时候，诸如“重新运行”和“
魅力”中的报告之类的工具确实足够，您可以从屏幕截图和步骤中了解测试崩溃的原因。 但是，最好的助手通常是能够在本地运行测试，按步骤进行操作或在调试模式下运行它们，以及查看预期的和实际的xpath。 没有处理测试项目的经验，这将花费大量时间，或者有必要分散专用的自动化工具。
此外，自动测试的独立编写使即使在该功能发布之前也可以运行它们。 测试人员始终知道系统部分的覆盖范围，并且技术任务仅在自动测试时滚动，从而大大节省了团队时间和资源。 测试本身总是相关的，因为崩溃是在发布之前进行调整的。 损坏的测试会在写入新测试的同一分支中立即得到纠正。
手动测试人员最大程度地沉浸在团队的工作中，因此，选择了必要的最少自动测试，涵盖了大多数情况。 在测试过程中，对样本进行了多次修订，因为在手动检查过程中，所有细微差别都会对功能进行更详细的研究。 因此，这种测试的效率正在增长。 编写自动测试可以使您更好地了解应用程序的体系结构，使用的组件以及与后端的前端交互。 最终，这些知识将有助于以更自觉和有效的方式进行产品测试。 例如，如果某个命令对常规组件进行了更改，则您更有可能事先知道您的范围是否会受到影响，因为使用xpath时，您会了解在应用程序部分使用了哪些组件。
可以说编写自动测试需要时间。 是的，任务将比平常晚一到三天发布，但从长远来看，它会得到回报。 此外，还有优化方法。 例如，在开发功能时，您可以草拟必要的清单并为测试添加空白，从而节省时间。 如果您有现成的功能框架，则可以添加或修复现有的xpath，如有必要，可以创建新的Page Object或调整步骤。 然后，在编写自动测试的阶段，经过手动检查，您只需要按正确的顺序添加代码块即可。
多亏了我们的自动化团队开发的框架，编写自动测试的大部分内容代表了从块（如Lego）中编译代码。 这种简单性使您可以快速适应手动测试仪，并开始类似于现有测试仪来编写自动测试仪。 根据我自己的经验，我会说从我去Wrike工作到我编写的第一个自动测试以及其他任务大约花了两个星期。
书面自动化测试的质量控制是通过代码审查进行的。 未经审查，没有一个测试分支进入发行版。 这是一个很好的培训时机，因为测试人员从代码注释中获取有用的信息，并积累了良好解决方案的经验：例如，它可以更有效地管理标准Java库或更精确地定义xpath。 下次将很清楚如何在特定情况下最好地工作。
当然，测试项目的开发，框架和手动测试人员的培训会占用自动化资源，尤其是在初期阶段，但是在我看来，这些努力已获得全部回报。 我们在自动化测试环境中进行了许多改进，使我们的工作更加轻松。 产品本身具有良好的覆盖率，因此您可以依靠回归。 这有助于加快将功能推出到用户环境的过程，并极大地保护了测试人员的神经。
根据我们团队的经验，这是在大型公司中使用大型且快速开发的产品的最佳流程之一。 此外，它与提高软件质量和向用户交付软件的速度方面的当前趋势一致。 测试人员本人实际上摆脱了常规，在多个方向上进行开发，并从多个角度审视了应用程序。
简要介绍主要内容
为了方便起见，我将在一个地方强调手动测试器的优点，以便更轻松地单独或一起认识它们的重要性：
- 关于示波器的自动化水平和质量，形成了更加完整的图景。
- 在该功能发布之前，可以进行自动测试，从而可以随时快速检查其质量。
- 自动测试的效率会有所提高，总体而言，测试效率也会提高；
- 正在形成一种更明智和有效的测试方法；
- 摆脱单调的手工回归和冗长的评估测试；
- 个人成长和能力发展。
总结一下
当然，没有银弹。 适用于一家公司的东西可能会被另一家公司急剧拒绝。 就Wrike而言，产品增长非常快，没有时间进行冗长的手动回归和评估测试。 我们通过自动测试来扮演这个角色，该测试几乎涵盖了大型产品的每个组件。 这有助于保持质量，优化资源并更快地向用户提供新功能。
坏消息是它不能没有错误，但就我们而言，大多数情况下都是极端情况。 好消息是，修复过程中的错误也随自动测试而大量增长。
由于某种原因，它在社区中变得如此普遍，以至于拒绝由手动测试人员编写自动测试的想法。 测试人员最普遍的争论有两种：“他们为此不支付额外费用”和“我们已经有足够的工作量”。 就我个人而言，当我意识到我可以在开发功能时进行自我测试并在很短的时间内了解其正常工作方式时，这两种论点就会瓦解。 值得很多。 我们的工作是改善和保持产品质量，因此要抓住每一个机会来促进它。 从我开始编写自动测试的那一刻起，我工作中的例行工作就变得越来越少。
PS：本文仅反映我们团队的经验，可能与您的信念不符。 因此，我将很高兴知道指导您工作的方法。 我也将对健康的批评以及在评论中讨论文章的机会感到满意。