每五个QA求职者都想学习如何进行自动测试。 并非所有公司都能在工作时间内满足手动测试人员的这种愿望。 Wrike为员工开设了一所自动化学校，并实现了许多员工的这种愿望。 我是作为QA学生参加此学校的。
我学会了如何使用Selenium，现在我几乎在没有外部帮助的情况下就独立支持一定数量的自动测试。 并且，基于我们共同经验的结果和我的个人结论，我将尝试得出最理想的自动化学校的公式。
Wrike学校组织经验
当对自动化学校的需求变得明确时，其组织落在自动化技术负责人Stas Davydov身上。 除了他，还有谁能解释为什么他们提出了这个倡议，他们是否取得了成果并且不为所花费的时间感到后悔？ 我们请他发言：
-在2016年，我们编写了一个新的自动测试框架，并使该框架变得易于编写：出现了正常步骤，结构变得更加容易理解。 我们有一个主意：我们需要吸引所有想要编写新测试的人，但是为了使其更容易理解，我们创建了一系列讲座。 我们共同提出了一个计划，供将来的每位讲师使用，并准备一份报告。
-学生的困难是什么？-当然，基本上是建筑。 关于我们的测试结构，存在很多问题。 在反馈中，我们就该主题写了很多文章，并且我们不得不进行其他讲座以进行更详细的解释。
-学校还清吗？-是的，绝对可以。 多亏了她，许多人参与了编写测试的工作，平均而言，在医院里，每个人都开始更好地了解什么是自动测试，如何编写以及如何运行。 自动化的负担也有所减轻：自从测试人员和开发人员开始在几乎所有情况下自行解决这一问题以来，我们现在收到的关于分析测试的帮助请求数量减少了几倍。 嗯，部门有一些内部优势：他们在演示和讲座方面积累了经验，因此，一些自动化人员已经设法在会议上进行演示，并且还收到了一套功能强大的视频和演示文稿供新手使用。
就我自己而言，我还要补充说，我们部门之间的沟通已简化到了非常容易的程度。 例如，现在我几乎不需要考虑为自动化提供何种情况和原子级别。 结果，对测试覆盖率的关注在不断增加，完全来自所有相关方面。 没有人要求别人做到不可能。
通常，对团队合作的影响是独特的。 也许阅读本文的同事也正在考虑持有这样的东西？ 这样的建议将很简单：如果您优先考虑自动测试，那么这是值得的。 接下来，我们将讨论一个更复杂的问题：如何尽可能正确地组织所有事务，以使各方的成本降到最低，并使工作量最大。
组织技巧
这所学校很有用，但正如Stas所承认的那样，存在一些困难，因此有必要安排更多的讲座。 就在这名刚刚学习比较无知与现在的学生的过程中，我制定了以下步骤，以创建理想的方法，以教会测试人员如何进行自动测试。
步骤0。创建字典
当然，不仅要进行质量检查，还需要执行此步骤。 但是，我想明确地说：自动化代码库应以可读的形式存储。 编程语言尤其是
语言 ，由此您可以开始潜水。
这是taskview的屏幕快照，其中包含元素的名称。 想象一下，您正在像黑盒子一样执行任务视图，而您一生中从未见过Selenium。 该代码的作用是什么？
（剧透-其余部分代表管理员删除了任务，然后我们在流中看到关于此的记录。）
仅此一步就可以使QAA和QA语言更加接近。 自动化程序可以更轻松地解释运行结果；手动测试人员在编译案例时需要花费更少的精力：可以简化工作流程。 但是他们彼此了解。 甚至在培训本身开始之前，我们就取得了胜利。
步骤1.重复短语
我们继续与舌头平行。 当我们在童年时期学习说话时，我们不会偏离词源和语义。 我们重复“母亲”，“购买玩具”，但是我们并没有立即提及这些词在印欧语之前的含义。 因此，在这里：深入研究自动测试的技术功能毫无意义，而无需尝试编写一些有用的东西。
听起来有些违反直觉，但确实有效。
在第一课中，值得为如何直接编写自动测试提供基础。 我们帮助建立开发环境（在我的情况下为Intellij IDEA），解释使用可用步骤在现有类中编写另一种方法所必需的最低语言规则。 我们用它们编写一个或两个测试，然后做作业，我将按以下步骤设计：从主服务器分配一个分支，但其中删除了几个测试。 仅保留其描述。 我们要求测试人员恢复这些测试（当然，不要通过show diff）。
根据结果，倾听并做了所有事情的人将能够：
- 学会使用开发环境的界面：创建分支，热键，提交和推送；
- 掌握语言和类结构的基础知识：在何处注入，在何处导入，为什么需要注释以及除步骤外的一般符号有哪些注释；
- 了解行动，期望和验证之间的区别，在哪里使用什么；
- 注意自动测试和手动检查之间的区别：在自动测试中，您可以拉一个或另一个处理程序，而不是通过界面执行操作。 例如，直接将注释发送到后端，而不是打开任务视图，突出显示输入，键入并按下“发送”按钮；
- 提出下一步将要回答的问题。
最后一点很重要。 这些答案可以很容易地提前给出，但这是一个重要的教学原则：没有公式化问题的答案将不会被记住，并且在最终需要时不适用。
如果当时QA团队自动化员在战斗中编写一些测试并允许他致力于自己的任务，那将是一件非常理想的事情。
您不应该给的：
- 对开发环境的功能和编程语言本身有更深入的了解，只有与分支独立工作时才需要这些知识。 我不记得了，我必须解释两次或三次，我们很重视自动化的时间，对吗？ 示例：解决冲突，将文件添加到git，从头开始创建类，使用依赖项；
- 与xpath相关的所有内容。 说真的 您需要一次，非常集中地谈论他。
第2步。我们看一下语法
让我们从第0步中调用带有taskview的屏幕截图。 我们有一个名为checkCommentWithTextExists的步骤。 我们的测试人员已经知道此步骤的作用，您可以查看该步骤的内部并将其分解。
在内部，我们有以下内容：
onCommentBlock(userName).comment(expectedText).should(displayed());
哪里onCommentBlock
onCommonStreamPanel().commentBlock(userName);
现在，我们学会了说的不是“买玩具”，而是“从Detsky Mir商店买玩具，它站在上方第三个架子上的蓝色柜子里。” 有必要说明一下，我们是从较大的元素开始依次指向该元素的（stream->具有某人注释的块->给定文本所在的该块的该部分）。
不，仍然不是时候谈论xpath。 简而言之，所有这些指令都是由它们描述的，继承是通过它们进行的。 但是您需要讨论所有这些测试器和传送器，它们与这一步骤相关，并且对于了解正在发生的事情是必需的。 但不要超负荷：您的学生以后可以自己学习更复杂的练习。 最有可能的是，waitUntil应该显示（）;存在（）;，而不是（）;。
作业是显而易见的：分支中删除了多个步骤的内容，这对于一定数量的测试是必需的。 让测试人员恢复它们，并使运行再次变为绿色。
此外，如果测试人员团队不仅具有新功能，而且还具有一些错误修复，则可以要求他立即为这些错误编写测试并放弃它们。 最有可能的是，已经描述了所有元素；仅可能省略了两三个步骤。 这将是完美的锻炼。
步骤3.完全浸入
对于将继续履行其直接职责的测试人员，尽可能地完善。 最后，您需要谈论xpath。
首先，我们很清楚所有这些onCommentBlock和comment均由它们描述。
总计：
"//div[contains(@class, 'stream-panel')]//a[contains(@class,'author') and text()='{{ userName }}']//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}')]"
故事的顺序很重要。 首先，我们采用任何现有的xpath并显示在elements选项卡中如何只有一个元素。 接下来，我们讨论结构：何时需要使用WebElement，何时需要为新元素创建单独的文件。 这将有助于更好地理解继承。
必须明确地说，单个元素就是全部taskview，它包含一个子元素-包含该子元素的整个流-一个单独的注释，等等。 子元素-在页面上和自动测试框架的结构中均位于父元素内。
在这一点上，听众应该已经对他们如何继承以及在onCommentBlock之后可以输入什么有扎实的了解。 至此，我们解释了所有运算符：/，//，。，[]依此类推。 在负载中，我们证明了有关使用
@class和其他必要事物的知识。
学生应该了解如何以这种方式翻译xpath。 要解决-对，功课。 我们删除元素的描述，让它们恢复测试的工作。
为什么要这样呢？
我们不应该使一个拥有复杂知识的人超负荷工作，而必须立即解释所有事情，这是一个困难的难题。 这种方式将使我们能够首先使听众提出问题，而听不懂某些内容，然后在下一刻回答。 如果我们讨论整个体系结构，那么在分析步骤或xpath的主题时，由于它们的不可理解性，它的最重要部分已经被忘记了。
尽管如此，你们中的一个人也许可以分享更多关于如何优化流程的经验。 我很高兴在评论中阅读这些建议！