过去十年中，开发方法发生了重大变化，对测试人员（QA，QE，质量工程师）的要求也发生了变化。 但是，并非所有测试人员都准备迈入一个全新的台阶。 昨天有可能从大街上进入这个行业。 要成为今天广受欢迎的专家，您需要成为一名工程师。
在开始职业生涯时，在课程中显示了一个演示，证明了测试的必要性。 幻灯片的签名是：“越早发现产品生命周期中的错误，修复起来就越便宜。” 测试率低于程序员。 我们聘请测试人员→确保质量并节省开发成本。 赢利！
测试人员是bug猎手。 程序员编写功能，正在准备发布，该发布经过QA阶段。 那时，测试人员“戴上帽子”真正的用户，并开始执行典型的方案。 人们认为没有技术背景的人将适合这个职位。
现代项目的发展速度加快了。 CI / CD的概念出现了。 每日发布的项目没有人感到惊讶。 公司意识到手动检查是不可扩展的。 测试人员使用Selenium或类似框架进行了验收测试的自动化。 如果只有前端保留必要的定位器，则内部的更改将被隐藏。
原来如此。 对于管理人员而言，测试自动化与一项技能相关联：使用Selenium。 为了追求一个银弹，他们在他身上看到了所有问题的答案。 市场已根据需求进行了调整。
长期以来，我们一直在寻找用于测试Web服务的质量检查自动化。 我浏览了数百份简历，并进行了数十次采访。 如果要总结印象，则可以区分出三个主要问题，这些问题通常使一个人无法雇用。
1.测试人员对项目的架构一无所知
在这里，通过体系结构，我的意思是对系统组件交互的高级描述。 按照惯例，数据通过哪些“管道”流动，存储在何处以及如何使用。
他们说，在面试中，候选人可能会反对，我们不需要建筑知识。 我们使用黑匣子。 为什么要照顾内部结构？
我不认为采用这种方法，工程师会提出所有可能的测试方案。 如果您知道产品的内部结构并阅读了代码，则可以避免在测试金字塔的高级别重复测试。
马丁·福勒的金字塔变形
在黑匣子测试中，存在与通过隐瞒安全性相同的陷阱。 您不能仅依靠这种类型的测试。 该产品可以满足规定的要求，同时还包含大量隐藏的错误。 然后，通过模糊性与安全性进行类比，质量的唯一保证将是我们对系统内部结构的无知。
黑匣子测试的优点是测试独立于实现。 哇 但是这种人为的限制不应干扰对内部的理解。 当测试人员知道产品如何工作时：
- 面对错误，它可以定位问题，而不建立假设。
- 在讨论新功能时，他准备提供反馈，因为他了解新功能如何与现有组件集成。
Malevich鼓动测试黑匣子
对黑匣子的热爱可能导致了第二个问题。
2.测试人员不了解浏览器内部正在发生的事情
通常，在简历中将Selenium作为主要工具的应聘者可能不了解浏览器和HTTP协议的工作方式。 对此类自动化器的测试主要是创建具有用户操作的脚本。 一种产生不必要限制的肤浅方法。
大多数申请人都列举了HTTP代码和HTTP请求类型的示例。 下一个问题常常令人困惑。
有一个登录页面。 用户输入正确的数据进行授权，然后单击登录按钮。 此时浏览器中正在发生什么？ 为什么对该网站执行的后续操作不需要重新授权？
如果测试人员没有回答这些问题，则会对他的能力产生怀疑。 这表明候选人：
- 没有用户界面就无法测试产品；
- 不知道如何在浏览器中使用开发人员工具；
- 我不习惯找出错误的原因（前端或后端）。
如果使用技术细节进行描述，则开发人员将更容易修复该错误。
3.对测试代码的过失态度
“我的代码无法投入生产，为什么还要关心质量？”
我认为这是尝试拆分沙箱的一种尝试。 让开发人员照顾代码的整洁度，但是我们可以。
还记得开发后的级联模型中有一个验证阶段吗？ 在瀑布方法学研究期间，质量责任移交给了测试部门。 它并没有带来任何好处。 程序员没有考虑该功能的就绪性，而是希望质量检查报告问题。 部门之间的乒乓球导致发展放缓。 这是分担责任的代价。
随着敏捷的到来，团队已经合并。 缺少“我们”和“他们”。 团队负责最终结果。 并且由于工程实践已变得很普遍，因此对测试代码的要求应与对产品代码的要求相同。
为了淘汰候选人，我们发送了没有截止日期的测试任务：
Java http://todomvc.com/examples/react/
常见错误列表
额外的并发症
测试中有大量的抽象，类的包装和样板代码。
测试方法最好尽可能短。 助手功能以及将设置与对象和检查操作分开将对此有所帮助。
违反类，方法，变量的命名约定
CamelCase与下划线混在一起。 所以他们现在不戴它。 Linter和IDE提示保存。
硬编码辅助路径
String exePath = "Chrome_driver/chromedriver.exe"; System.setProperty("webdriver.chrome.driver", exePath);
经典的“可以在我的机器上运行”。
将二进制文件存储在存储库中
有git-lfs解决这个问题。
方法缺乏一致性
在一个解决方案中，候选人描述了删除和标记“完成”的方法，如下所示：
public void DeleteTask(String task) ... public void CompleteTask(int taskno)
在第一种方法中，传输任务文本，在第二种方法中，传输列表中的索引。 使用这样的API很痛苦。
System.out.println()用于记录
它不提供事件发生在哪个类别的支持信息。
使用Thread.sleep
为了解决这个问题，有一个等候室。 它有助于将反馈添加到满足必要条件的期望中。
一般例外而不是断言
示例：测试将多个项目添加到任务列表中，并将所有项目标记为已完成。 这个想法是在出现问题的情况下， findElement方法将返回NoSuchElementException ，并且测试将NoSuchElementException 。 如果稍后查看测试运行的结果，则NoSuchElementException将产生误导作用：尚不清楚测试是否真正下降或测试曲线的代码。 如果测试失败，则必须使用带有清晰错误消息的声明。
滥用Bertic Acerts
assertTrue或assertFalse用于一行中的所有内容：
assertTrue("One To Do item should be added", toDosPage.getToDoListCount(false) == 1);
最好在测试崩溃时在这里使用assertEquals来获取上下文。
没有用于运行测试的参数化
示例：用于测试的网站URL已添加到代码中。
我们还应该提到使用git 。 通常，任务是在一次提交中发送的。 编写可理解的提交消息并将大任务分解为几个单独的消息是必不可少的技能，尤其是在团队合作中。
结论
上述问题是我的个人经历和面试后的印象。 根据观察，候选人的经验与空缺的数量无关。 避免使用顺势测试仪，将时间花在提升员工的技术技能上。 测试人员可以向开发人员学习，反之亦然。 可能会伴随那些建立工程文化并逆潮流而行的人来。
如果您雇用的公司中的一切都不同，我会很高兴被误解和高兴。
UPD 11/02/20 ：在网络研讨会“测试员的肖像”上，我对我如何从内部看待专业发表了自己的看法。
- 为什么企业需要测试人员？
- 测试人员在团队中的角色
- 手动VS自动化测试
- 专业的吸引力和经验的代价
- 必要的软/硬技能
- 新手专业人员简历中的错误
- 开发测试
- 职业成长