测试人员,不止于自动化!

2024-03-31   出处: Satisfice  作/译者:James/暖阳

Muhammad Saad在LinkedIn上发布了一个有趣的场景,我将在下文用斜体字引用它,并对此进行评论……

想象一下你作为测试人员第一天上班的情景。你被要求测试一个应用程序。这是一个包含数百个表单和数千个报告的ERP应用程序。你开始进行探索性测试,打开了一个包含大约50个字段的表单。

你尝试在这个表单中输入随机数据,这大约花了20分钟。然后你点击提交按钮。哇!显示了一条错误消息,看起来像是一个未处理的异常。你感到非常高兴,自豪地记录下步骤,并在缺陷管理系统中报告了这个bug。你的努力得到了回报,你感到非常自信,干劲十足。你继续测试,直到当天结束,并发现了更多的bug。你不禁感叹:第一天真是太棒了!

这样的第一天确实不错。作为测试人员,你的前几天甚至前几周都充满了学习。而学习的一个重要部分就是研究被测产品。要想做好测试,你必须对产品有足够深入的了解。你可以通过多种方式获得这种能力,但通过直接使用产品来进行有趣和开放的探索过程,我在RST(Rapid Software Testing)中称之为“调查测试”,可能会比其他方式都更有效。

接下来是第二天,开发人员修复了问题并发布了一个新版本。你用同样的步骤测试了同一个表单,发现bug已经修复。你将其标记为已修复。太棒了,你通过发现该错误,为产品质量做出了贡献,随着错误被修复,产品质量也得到了提高

在这一天里,还有很多其他事情要做。你可能没时间去验证bug修复。也许其他人会去验证,也许可以等等。你有很多东西情要学习和测试。尽管如此,在第二天验证修复还是有可能的。

我的测试经验越丰富,我对“为质量做出贡献”的兴趣就越小。我的兴趣在于对产品进行全面的监控,以便没有任何问题能够逃过我的法眼。我发现质量本身就是一个分散注意力的概念,但我理解,很多人都乐于把产品做得更好。到目前为止,Muhammad的故事还不错。

第三天,开发人员又发布了新版本。现在,你又要测试该表单,确保没有任何回归问题。同样是 20 分钟。现在你觉得有点无聊了

同样的 20 分钟吗?感到无聊吗?不对,两个问题答案都是不。不是同样的 20 分钟。我每次测试的方式都不一样。我会扩展和改变数据。我会考虑可能帮助我生成更好数据的工具。我可能在与比我更了解产品的人交谈(如果这是一个成熟的产品,那么我肯定不是第一个测试它的人,如果它不是一个成熟的产品—它怎么可能已经有了数百个表单和报告呢?) 现在才是第三天,对于像 Muhammad 描述的这样复杂的产品,还有大约 200 天的密集学习等待着我。

我并不无聊。我致力于寻找更巧妙的测试方法。我正在学习这项技术的功能、操作和技术细节。这么短的时间就感到无聊的人,很可能不是热爱测试或对测试非常了解的人。测试并不仅仅是按下按钮和检查输出结果。测试是一种不断运用判断力的过程,你需要收集证据并从中理解其意义。

如果你不断重复一开始的那种浅层次的测试过程,那么我猜你很快就会感到无聊。但是我的测试会随着时间的推移变得更加深入,直到达到一定程度,然后随着我学会准确地知道在哪里进行关键观察,它在策略上又会变得更简化。

Muhammad可能是在简化这个故事,以便更清楚地表达他的观点。也许当他说“第三天”的时候,我们可以认为他指的是“第 20 天”,并对他的说法保留一定的怀疑态度。

现在想象一下,从现在起的一个月内,新版本会不断发布,而每发布一个新版本,你都必须测试这个冗长的表单以及其他 100 个类似的表单,只是为了确保回归没有问题。

现在你感到愤怒,感到疲倦。你开始跳过一些步骤。你只填写了50%左右的字段。你的准确性不一样了,你的精力也不一样了,毫无疑问,你的步骤也不一样了。

然后有一天,客户在同一个表单中报告了同样的错误。你觉得自己很可怜。你现在感到没有自信。你认为自己能力不足。管理者都在质疑你的能力。

我有个事情要告诉你:这是90%的测试人员的故事,他们在测试中没有使用代码/工具。

也许 Muhammad将他对测试过程的不满投射到了其他测试人员身上。我认为他对其中一些测试人员的看法是对的。确实,有些测试人员可能会感到愤怒、无聊和疲惫。但我强烈反对他的观点适用于那些热爱测试、研究测试并以此为职业的人。

回归测试是由回归风险驱动的。如果没有回归风险,就没有必要重新测试。因此,回归测试的负担比他说的要轻得多。除非开发人员完全失控、不计后果,否则回归风险不会很高。旧的 bug 很少会重新打开;产品的稳定区域也不会像罗马省的叛乱分子一样突然地爆发出 bug。通常更重要的是进行主流程测试,因为它能发现长期存在的错误。

此外,重新测试并不是完全重复第一次所做的工作。最好在测试中引入大量变化。这可以帮助你发现新的错误,以及那些你可能在第一次测试中遗漏的bug。

如果你对自己没有信心,这对一个新的测试人员来说是正常的。经验丰富、训练有素的测试人员知道“测试是困难的”并将他们对进度的期望保持在一个合理的水平上。即使你能力超群,管理者也会质疑你的能力,因为这些管理者可能并不是专业的测试人员。他们并不清楚测试是如何工作的。他们可能有一些模糊的想法,认为所有的测试都应该自动化。

然而,测试本身是无法自动化的。可以自动化的是某些固定的输出校验。我同意Muhammad的观点,自动化在大多数项目中都很重要,尽管我通常发现自动化最好由工具专家在测试人员的建议下完成,而不是由测试人员自己来完成。你必须始终牢记自动化能做什么和不能做什么,以及体验式和交互式测试(很多人称之为“手工”测试,但我认为这个词是侮辱性的,也是不准确的)能够发现自动化永远无法发现的错误。

回归问题是最令人痛苦的问题。我们是人类,无法每天都以同样的精力、速度和准确度做同样的事情。这是机器的工作。这就是为什么我们需要自动化

回归的bug并非最令人痛苦的bug。最令人痛苦的bug是那些对用户造成最大伤害的bug。与“回归”相关的bug并没有表明这样的 bug 特别严重。我想找到每一个严重的bug。

Muhammad在重复一个老掉牙的事情,而我在25年前的文章《自动化测试的误区》中首次攻击了这个观点。他似乎认为机器可以复制人类的工作。事实并非如此。他似乎认为自动化的创建和维护成本不高。实际上,它相当昂贵,尤其是相对于它能发现的bug数量而言。

我重申一下:我认为在每个项目中都要考虑自动化;对于某些项目来说,它绝对至关重要。但这也需要相当多的工作量。很容易创建许多低价值的检查项,而这些检查又必须随着产品的变化而维护。Muhammad 所描绘的是一个人手严重不足的项目,而且显然已经很长时间没有测试团队了。解决测试问题需要时间,管理层必须要有耐心。

绝不能让自动化本身成为一种痴迷。我个人有很多关于编写工具的经验(我的职业生涯是从开发人员开始的,我喜欢编写代码来帮助测试),也时常沉迷其中。但我知道,我需要身边的人帮助我保持客观的视角。

作为一名专业的测试人员,我的工作涵盖测试策略、测试文档、测试执行、开发测试数据库、开发测试工具、配置测试平台、报告缺陷、倡导可测试性、学习产品以及理解用户。我正在从事许多有趣而具有挑战性的工作!自动化只是我所面临问题的一小部分。


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
150° /1500 人阅读/0 条评论 发表评论

登录 后发表评论