为什么许多工作描述自动化但又需要大量的手动测试？

#1 楼

遵循怀疑论者SE准则，我希望像您这样的问题会附有消息来源，否则只是一些轶事而已。

要回答您的问题，我的经验和知识正好相反，越来越多的公司开始使用现代测试或某种形式的组合工程，这些测试和质量由整个团队拥有。 >
在这些团队中，测试人员充当专家的角色，例如通过启动自动化框架并教团队使用它们或指导其他人（即开发人员）如何设计和执行更好的手动测试，来帮助团队实现其目标。

如果说自动化工程师是永久性的进行手动测试的昂贵选择，但现实情况比任何理论都强大，有时公司会承受压力，使用手头的可用资源来解决眼前的问题使用资源的效率低下。

#2 楼

我观察到的是，很难聘请擅长于自动化以及自动化所需要的特定技能的优秀程序员。测试。所有其他类型的“其他人编写测试自动化程序”（正如我所说的那样）会导致很多沟通和目标问题。

尝试雇用优秀的技术QA人员的过程通常会有所进展像这样：

公司遇到质量问题\|/
他们需要自动化专家\|/
大多数申请人是手动测试员还是... \|/
大多数技术候选人宁愿做应用程序开发人员，也要给他们更多钱。
选择过程是由具有不同优先级的应用程序开发人员完成的。

上述过程意味着对自动化专家的技能常常了解甚少。例如，许多自动化编程访谈都涉及递归，性能，Big-O等主题，而不是诸如BDD，敏捷测试金字塔方法和Test Suite DSL之类的自动化实际所需的技能。 >许多刚进入该领域的面试官通常仍处于学术竞争和测验证明能力的模式。根据应用程序开发人员的说法，当质量检查合格申请人没有“很好地测试”时，结果通常是确定质量检查合格申请人没有编码所需的条件。我看到这个悲伤的故事对我与之密切合作的许多同伴播放了数十次。所以我也有经验可以借鉴。不只是我自己有限的经验-尽管我也有几十年的经验，并且在过去的20年中，我的许多同事也反复观察到这种模式。就像这样简单：


应用程序代码可提供当今的收入，并且最容易证明业务合理性
为应用程序开发人员支付更多费用会带来更好的结果

#3 楼

我可以举一个我们公司的例子，它几乎与您所描述的相同。让我简短地解释一下我们的工作方式。我们有两个部门，一个部门是IT部门-拥有测试人员（手动和自动测试人员），而我们的业务部门也拥有测试人员（更多的内部测​​试人员和手动测试人员）。我们的大多数工作都完成了两次，但是，当我们在生产环境上进行部署时，我们发现了很多错误。因此，我们还决定作为业务部门进行自动化测试。我们从Selenium和Appium开始，并且我们还鼓励雇用自动化测试人员（在这种情况下，我们聘请了顾问）。作业（意味着创建测试用例，记录错误，重现错误，无论这些错误是否是有效的错误，等等）。正如您已经说过的那样，他的个人资料是80％的手动和20％的自动化，而不是80％的自动化和20％的手动任务。

原因是什么？

1。新的Web应用程序每天都会更改定位器

好了，我们得到了测试新Web应用程序的任务。但是，此Web应用程序某种程度上是一个营销网页。定位器（xpaths，ccs-locators ...）几乎每天都在变化。因此，作为业务部门，我们更加专注于测试E2E应用程序。但这不是E2E应用程序。目前，创建自动测试用例已经没有意义，我们没有时间创建测试用例并每天进行更改。因此，我们进行了探索性测试。此外，我们必须评估测试自动化是否有意义。我们使用QaSymphony / Tricentis进行了探索性测试，并在测试时进行了测量，与自动化测试相比，探索性测试节省了更多时间。

2。无需测试自动化-开发人员完全可以做到这一点

不知何故，这对我们也是一场斗争。我们的产品负责人说开发团队已经完成了测试自动化，因此不需要测试自动化（！）。但是他不明白，开发人员无法替代测试人员（组织盲目性）。此外，开发仅测试了整个应用程序的一小部分，并进行了某种程度上的大部分单元测试。

3。预算问题

我们有很多人离开该项目或担任其他职务。预算也减少了。测试自动化要花钱，业务部门（起初）不愿意为测试自动化付钱，因为我们不得不说服产品负责人及其部门。但是也需要测试应用程序-但是从业务部门的角度来看，手动测试是足够的！

4。没有时间进行自动化测试-快速进行测试

这对我们来说也很重要！作为一个小型测试团队，我们只负责2-3个应用程序。但是管理层决定超过一些应用程序。而且，由于我们的小型测试团队，很难协调所有测试活动。因此，我们专注于相关的测试用例，并从手动测试开始，而不是建立测试自动化策略。最后，我们的测试自动化工程师正在执行80％的手动测试和仅20％的自动化测试（这只是为了准备测试环境并创建第一个测试用例）。管理层希望尽快看到结果！此外，我们必须专注于重新测试错误（由于我们是业务部门，因此我们必须以某种方式进行UAT并验证该错误已不再可用）。

5。防火墙和其他技术资料的问题

在我们公司中，我们也有严格的政策，不允许我们引入测试自动化和使用例如Selenium＆Appium并将它们与真实设备连接。最初，我们要求顾问在其设备上创建并运行自动测试用例！这是一个解决方案，但这花了我们至少1-2个月的时间（订购iPhone等设备）。在开始时，这导致我们的测试人员感到沮丧，他们愿意引入新的东西。

这些（还有更多:-)）是我们所教的课。但是最后，我们可以说以某种方式设法以50％到50％的基础引入测试自动化（50％的测试自动化和50％的手动测试）。

#4 楼

我只是在重新排列您的问题顺序，以便可以更清楚地回答：


这种趋势是特定于公司的吗？答案将比组织更特定于产品和测试级别。

让我们看看不同测试级别的自动化方法：

系统测试：

关键应用程序

考虑关键银行应用程序，网络设备，服务器技术等，在这种情况下，公司不会冒着将容易出现缺陷的产品投放市场的风险，希望以后可以修复任何生产错误。

在这种紧急情况下，公司会聘请领域专家对产品进行严格的深入手动测试。手动测试人员编写适当的手动测试用例，然后将其移至专门的自动化团队，以自动化整个工作流程。在这里，我们可以看到100％的手动团队和100％的自动化团队。

非关键应用程序：

在这种情况下，缺陷检测百分比将不被视为成为关键指标。在这里，测试人员只需要覆盖最重要的功能范围（如果我们将安全性视为另一个层次）。在这里，公司不需要专门的手动测试人员来执行严格的手动测试。他们需要更多的QE工程师，他们会识别手动方案并将其自动化，然后将其集成到CI / CD管道中。这种方法最初侧重于找到尽可能多的手动方案，然后在将来的sprint中将工作量更改为80％的自动化和20％的手动。 （这就是您在问题中所说的）

API测试：

在这里，我们甚至可以自动化关键应用程序。如果有适当的API文档，您甚至可以在产品开发之前就开始编写自动化的API测试用例（测试驱动的测试）。可以使用虚拟JSON响应编写自动化脚本。通过这种方法，我们拥有100％的自动化测试团队和0名手动测试人员。


原因是什么？提到的原因是投资回报率降低，公司成本增加。想象一下，您有一个专门的SDET，它对手动测试一无所知，因此在开始自动化之前，他们必须依靠手动团队的手动测试用例。同样，一旦产品变得稳定，手动团队将没有很多工作要做，并且对组织来说将变得多余。这就是为什么一些公司将手动测试外包的原因，因为他们认为手动测试可以给测试团队提供更多的独立性，并提供更高的缺陷保留率。

在这种情况下，公司雇用具有手动和自动化技能的候选人来进行测试手动仍然使产品变得成熟，然后并行自动化可以自动化的产品


纯粹的（或80％）自动化工作正在死亡吗？如前所述，自动化百分比取决于产品。每个质量保证人员都应该自豪地说“自动化脚本仅与手动测试用例一样好”。因此，如果您雇用测试自动化的开发人员，那么他所涵盖的场景将远远少于经验丰富的质量检查人员。

公司不在乎您是手动还是通过自动化（待评估）。因此，不要等到有人告诉您自动化某些东西，而只是将其自动化并作为PoC进行演示，那么它肯定会并入组织中。成为一个自我入门者，不要等待指示。


自动化测试仪的未来是什么？


自动化测试人员的需求比以往任何时候都要多，您找不到不需要自动化技能的工作。但是请记住，任何有逻辑的人都可以学习自动化，但是手动测试是不是每个人都可以掌握的才能。您应该非常热衷于打破东西，发现漏洞，戴白帽子之类的东西。关于CI / CD

#5 楼

我可以想到几个问题：


如果测试自动化工程师与软件工程师之间的距离太远，那么测试自动化就会失败。集成和部署。这意味着几乎所有软件更改都需要进行测试更改，以便在更改影响到API，服务体系结构或其他因素时进行测试。
在理想情况下，很少有东西需要进行两次测试。因此，测试自动化工程师需要知道软件工程师在单元测试和集成测试中所涵盖的内容，并且仅使其余部分自动化。为什么不将所有人都标记为“软件工程师”，并使测试自动化成为开发团队的任务？如果这样做的话，那些各种各样的程序员可能会很想将测试负载推给手动测试人员并代之以功能。
测试自动化需要良好的要求。
我经常看到要求（两者都在敏捷和瀑布式项目）对结果的描述不够好，无法编写自动化测试。取而代之的是您拥有软件和要求，并说“软件看上去与要求一致”。每当软件满足需求时，都必须以不同的方式调整测试自动化。
对于某些项目，如果要求足够好而无需参考软件编写测试，那就很好了。但是，这种文化变革必须在数月或数年后才能开始，测试自动化工程师才能开始工作。

#6 楼

您所看到的实际上是一种不常见的模式，不仅限于软件测试。

许多公司宣传他们想要的工作，而不是实际要做的工作。我敢肯定，在那里的经理们的脑海中，大多数测试都是自动化的，并且有少数情况需要手动测试。他们可能理解也可能不理解这是他们的愿景，但还不是现实。

这发生在很多工作中。有工作的想法，有实际的东西。它不一定表示恶意。通常是以下两种情况的结合：a）管理团队和b）一厢情愿。特别是如果公司正在从人工测试过渡到自动化，经理通常会认为他们走的路比实际情况要长。您应该是介绍或完成自动化的人，而细节在涉及的五个公司部门中都丢失了。尤其是在大型公司中，有很多人会混入职位描述，这很容易实现。

最好的方法是在面试中提出清晰的问题。例如，目前哪个测试部分是完全自动化的，以及他们打算在明年内将其推广到哪个测试部分。这两个数字将使您很好地了解与您交谈的人员了解实际过程的程度以及他们在实现更多自动化方面的积极程度。 （如果有人说“ 100％”，您就知道他们在欺负您）

#7 楼

我认为这是因为自动化仍相对较新，而且是一个流行词。

大多数组织都喜欢它的声音，它可以保证“立即回报”。

但是因为它太新了，所以他们只是不知道设置并正确执行它需要什么，也没有用于它的任何基础结构。因此，经过一番挣扎之后，请立即回到手动测试中。

#8 楼

我认为大多数公司在测试自动化实践方面都是较晚采用者。他们知道他们需要测试自动化才能变得更加敏捷，但是他们缺乏胆量来停止当前的开发工作三个月并扭转局面。产品至少具有2-3年的代码库。小型产品往往从小规模开始，并且测试，手工部署都很容易。

这就是问题所在，团队从做事手册开始。现在三年后，很难摆脱这些手动习惯，使其自动化成本很高。员工没有动力去挑战管理，接受他们的中间统治或认为这是工作安全。这就是为什么大多数公司都拥有纯传统产品的原因（例如，没有测试自动化的代码）。阅读如何使用旧代码有效地工作。

他们仍然试图为未来而雇用，但被困在过去。不只是谈话，还包括代码，测试，流程。要求在团队中工作一天。验证他们练习XP以及诸如持续交付之类的事情。大多数软件人都可以选择在哪里工作，因为需求量大于可以工作的人数。

#9 楼

我认为您基本上回答了您自己的问题。


但是一旦被录用，鉴于敏捷团队中发布版本的紧迫性，很多工作将涉及手动测试。 br />

很多人都有很高的抱负，但是时间和资源会限制诸如自动测试之类的延迟奖励工作。组织内部的人员可能对它的价值有不同的看法。无法立即交付的东西可能很难被企业主超越。

#10 楼

我曾经在波兰测试论坛上调查过25位测试人员，为什么很难找到测试自动化专家。其中之一表示，这是因为公司在工作机会上作弊：


许多寻找测试人员的公司声称他们需要有人来自动化或能够学习自动化，然后事实证明仅涉及手动测试，而自动化只是PR，可以说服候选人接受合同。当您签订合同时，几乎没有人辞职。


也许这是一个恶性循环。公司认为，如果涉及自动化，工程师会对测试职位感兴趣。因此，他们相应地描述了工作职位。工程师意识到这种误导性描述，因此只有经验不足的工程师才可以申请。

#11 楼

对我来说，他们想确保质量检查人员具有某种编码思想。由于任何人都可以通过学习系统（例如系统）来成为手工质量检查人员，因此端对端的工作流程就可以了。但是手动测试人员的主要问题是，他们不了解qa，dev和prod中的代码。因此，他们将其视为错误的所有内容，可能不是代码尚未推送到质量检查的错误。

因此，许多开发人员都希望QA对编码不了解，以便他们能正确理解。这就是为什么尽管他们不需要自动化或没有时间进行自动化，但他们仍在寻找自动化质量保证的原因。我只将自动化用于回归测试，以节省手动测试的时间，而将手动测试用于打开或查找错误。