专栏首页FunTester如何从测试自动化中实现价值

如何从测试自动化中实现价值

如果几年前,质量管理部门都试图通过ROI指标来证明对测试的投资是合理的,那么现在情况发生了变化,是时候重新审视这个问题了。当实施连续测试,并且每天在不同的环境下以不同的角色运行多次测试自动化时,由于测量方法与以前大不相同,因此ROI成为不合时宜的术语。试图衡量和证明测试投资合理性的未来5-10年的关键术语应该是VALUE。

连续测试的目的

在说明投资回报率一词之前,让我们先设定一下现代测试自动化尤其是连续测试的目标。

在敏捷测试宣言中,我用粗体标记了此类测试背后的关键价值。

  • 持续测试超过在种种环境进行测试。
  • 拥抱所有的测试活动而不仅仅是在自动化功能测试。
  • 在整个团队中进行测试,而不是在孤立的测试部门中进行测试。
  • 产品覆盖率超过代码覆盖率。

如果要应用上述方法,则此类测试的主要目标是通过整个团队对产品进行的高价值测试以及整个测试类型(功能性和非功能性)来识别业务风险。在上面的陈述中,除了测试的值之外,没有任何度量或量化方法。

连续测试的关键支柱

为了实现连续测试, 组织应着重于内部创建测试自动化的能力,并在可靠的实验室中以及一天结束时按需大规模执行它,或者使用智能方法分析结果以使测试有意义量化的结果数据。

如果上述支柱符合组织的测试策略和优先级,则用于创建和执行测试的工具和技术将相匹配是有具有非常重要的意义的。

这里最大的问题是:我该如何证明在上面的提到的方面进行的投资?有哪些相关措施?每个步骤中谁都拥有什么样的权利?什么样子才是正确的?

从投资回报率到测试价值

为了解决上述问题,让我们确定谁在当今的敏捷和DevOps实践中进行测试。提供高质量和高价值的软件是功能团队的责任。考虑到这一点,将业务测试人员,开发人员和测试自动化工程师一起工作,并创建自动化测试方案以及手动探索性测试以实现其目标。虽然可能有现代化的COE或质量领导职能来监督组织内部的测试策略,确定预算和工具,但实际工作实际上是在团队内部完成的。

如果您与我一致认为价值是测试中最重要的事情,那么让我们尝试将价值分解为度量:

  • 周期内的测试数量
  • 重复发现缺陷的测试数量
  • 导致CI作业失败的测试数量
  • 因根本原因(对象ID,实验室,编码技能,平台状态等)分类失败的测试数量

尽管还有其他指标,但上面的指标清楚地表明了测试实际上是否符合他们期望的发现错误,或者仅仅是在制造麻烦和软件团队浪费。

从一些市场标准来看,每个KLOC(1000行代码)平均存在10-15个缺陷,每个KLOC都有0.5个缺陷逃到生产中。如果遵循这个数字,很明显,现在发现和报告的绝大部分的缺陷都是误报。要在连续测试中取得成功,需要有纪律和对价值的正确衡量,以确保报告为错误的大多数失败测试确实存在问题,相反的情况会在整个DevOps团队中造成混乱。

考虑到这一点,团队必须承认测试质量和产品质量是及时的事实,因此,您需要不断地对其进行测量和维护,以获取产品的实际状态。

如何实现比价值?

长话短说,在测试生命周期中,只有一个地方可以提供整个测试活动的价值,这就是测试报告!

如果您从编写代码的那一刻起就考虑到测试的整个生命周期,包括调试,执行和提交到现行中,那么开发人员(无论可能是谁)都会在测试“通过”之时告别测试。在他的环境中。只有在正式测试周期中测试失败(可能是CI,其他事件触发的回归等)时,测试所有者和测试之间的团聚才会发生。这意味着,从测试集成到套件直到失败为止,都有一个盲区。除了对测试感到满意以外,没有真正的理由来复盘它(如果它当然是一项高价值的测试)。现在,考虑一下一组1000个平均失败率为10%的测试案例。这意味着我们现在有100个失败的测试场景,需要有人审查和报告。每KLOC 10-15个缺陷,事实表明至少有80%的测试不是真正的bug。该团队现在必须处理80个测试用例的调试,这些调试可能会也可能不会增加产品的价值。

我认为到目前为止,这一点很明确–> 测量测试自动化值是从上述指标开始的,并且大多数测试用例的概念在以10倍的时间作为回归运行时都不会揭示关键的错误。要了解哪些测试可以增加价值,什么没有增加价值,什么仅仅是误报和不稳定的软件工程,您需要对测试活动的每个领域都具有适当的测试报告和质量可视性。

底线–投资时间,即金钱的资源,应牢记这些测试的附加值。每个周期使用老式的通过/失败测试效果不错,但无法跟上当今技术的步伐,因此,需要对测试如何实时,随时间,针对每个平台,针对每个功能区域进行更认真的检查。不要太依赖您的测试代码,如果短时间后仍不能证明自己,只需删除它即可。您只能通过报告评估测试是否带来了价值。


本文分享自微信公众号 - FunTester(NuclearTester),作者:FunTesting

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-11-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 如何在DevOps中实施连续测试

    在过去的十年中,对软件开发的需求已急剧发展。软件已成为公司获得竞争优势的关键优势,特别是如果您的公司属于SaaS范畴。通过在SDLC中实施瀑布等传统流程,组织现...

    八音弦
  • 43种常见软件测试分类

    我们每个人在测试过程中都会遇到几种类型的测试。我们可能听过一些,也许已经做了一些工作,但是并不是每个人都了解所有测试类型。

    八音弦
  • 自动化的好处

    为了收集有关当前和未来自动测试状态的见解,我们询问了27家公司的31位高管,“通过自动测试解决了哪些实际问题?” 这是他们告诉我们的:

    八音弦
  • 软件测试成长目录

    这是我的第一篇文章,也是一个对自己未来发展的一个规划,希望自己能够坚持下来,每天进步一点点,加油!

    小雯子打豆豆
  • React全家桶与前端单元测试艺术|洞见

    TL;DR——什么是好的单元测试? 其实我是个标题党,单元测试根本没有“艺术”可言。 好的单元测试来自于好的代码,如果说有艺术,那也是代码的艺术。 注:以下“...

    ThoughtWorks
  • 软件测试分类有那些,你还知道吗

    回答以下小问题: 1.什么时候进行单元测试? 2.由谁来做单元测试? 3.单元测试的依据? 4.单元测试的通过标准? 5.国内单元测试的现状? 6.如何进行单元...

    用户7466307
  • 测试矩阵

    迷阵 “单元测试,集成测试,端到端测试,安全测试,性能测试,压力测试,契约测试,冒烟测试,验收测试,API测试,UI测试,兼容性测试……” 不知道你是不是像我一...

    ThoughtWorks
  • 移动应用的测试策略与测试架构 | 洞见

    今天我们来谈谈移动测试的测试策略与测试架构。 首先我们将移动应用的范围限定在智能移动操作系统(比如Android、iOS、WinPhone等)上,包括手机应用,...

    ThoughtWorks
  • 软件测试金字塔

    ? “测试金字塔”是一个隐喻,它告诉我们将软件测试分成不同颗粒度的桶,也给出了我们应该在这些组中进行多少次测试的想法。尽管测试金字塔的概念已经存在了一段时间,...

    DevOps时代
  • 程序员面试之软件测试面试问答

    1、问:你在测试中发现了一个bug,但是开发经理认为这不是一个bug,你应该怎样解决? 首先,将问题提交到缺陷管理库里面进行备案。 然后,要获取判断的依据和标准...

    互联网金融打杂

扫码关注云+社区

领取腾讯云代金券