对于许多人来说，手工测试仍然是进入 IT 行业的主要途径。我曾见过许多实习生和初级员工在初面时对开发职位表现出浓厚的兴趣，他们会不自信地问：”我怎样才能在贵公司转型为开发人员、设计师或分析师？”即使他们没有明确地说出这句话，他们的目标也很明确。这就带来了一个挑战：在短短的 1-2 个月内，这些候选人可能会失去继续担任手工QA 角色的动力，转而寻求转向其他角色。如果您有一个设计不断变化的跨平台混合应用程序，那么您的QA团队或许可以借鉴这种经验。

我们遇到的另一个挑战是招聘熟练的自动化工程师需要很长的时间。最初，我们认为由于因为入门门槛很高（复杂的应用程序、不同的版本以及 Mac/Win/Linux 操作系统上的实例等），只有高技能的自动化专家才能驾驭这种复杂性。我们考虑了一种不同的方法：简化复杂项目的外观，以鼓励包括手工测试人员和开发人员在内的各种专业人员作出贡献。

从我的角度来看，一个真正熟练的自动化工程师的价值往往被低估了。人们似乎普遍认为 IT 项目中的自然增长路径如下：

这种想法往往会将高级自动化工程师捧上神坛。然而，随着这些 “独角兽 “转型为开发角色，自动化框架的质量却越来越差。这主要是因为框架的结构变得不那么有效，代码的重复利用不够，经常需要从头开始创建自动化测试。

雇用更多员工似乎是一种解决办法，但 “数量不等于质量”。这需要对系统的构建方式和成熟的工作方法制定一个强有力的计划。从本质上讲，优秀的自动化工程师是对测试及相关技术和框架有深刻理解的开发人员。

为了更清楚地说明这一点，我现在将典型的自动化开发人员成长过程分解为几个阶段：

为了在公司可以有效地培养出QA专家，我们对产生负面效果的现有方法进行了改进。现在，我们为初级员工提供充分的激励和明确的目标，以促进他们的发展。

这一理念旨在建立一个全面且层次分明的系统，使其易于内部处理和外部开发。我们的目标是使用 “构造函数”，就像为被测应用程序的每个部分提供简单模板一样，编写测试并在连续的夜间分支上运行它们。我们将拥有足够专业知识的人员整合到一个团队中，以开发和维护强大的自动化解决方案。该团队参与创建了一个框架和用户友好界面，其中包括那些有用的工具和模块。该团队还提供文档，并与QA手工团队密切合作，告知他们新的变化，并协助他们有效地使用这些工具。我们得出这样一个框架的开发主要需要 3 级和 4 级的工程师。同时，前两级的自动化工程师负责监控自动化检查的覆盖范围并分析测试运行的结果。该框架非常简单，但如果需要，各个 IT 团队（如分析团队）中的积极主动的初级人员也可以编写此类测试。

在实施这种方法将近一年后，我可以说，重新评估团队内的角色帮助我们建立了更明确的目标，发挥了潜能，最重要的是，提高了手工和自动化团队成员的满意度。我很好奇其他公司的QA是如何应对类似挑战的。你们有哪些经验呢？