炮轰“测试左移”,向软件测试领域的“歪理邪说”宣战

为什么会有这么一个话题呢?很长一段时间,在软件测试领域,一直弥漫着一种悲观的氛围!比如说测试无用论,我们需要全职的QA吗,人工智能将取代测试工程师,测试工程师并没有办法为企业创造利益等等。

炮轰“测试左移”,向软件测试领域的“歪理邪说”宣战

由于一些人或组织有心或者无心的制造一些焦虑,让软件测试的从业者尤其是刚入行的软件测试工程师,对软件测试本身的意义,以及软件测试职业的发展、技术路径、充满了疑虑!在此,作为一个从业20年以上的软件测试工程师,一个ISTQB国际软件测试工程师认证的专家级证书获得者。我想谈谈自己的认识和看法,希望能给软件测试从业者一些我觉得正确的软件测试理念和观点。

第一炮我们先从“测试左移”入手,谈一谈我对“测试左移”的看法。

所谓的“测试左移”是什么?

通过百度的搜索,国内查到“测试左移”最早的描述起始于2016年年底到2017年年初。换句话说,“测试左移”是一个新概念。

最初在谈到“测试左移”这个概念时候,更多是指软件研发过程中的测试活动应尽早介入。

炮轰“测试左移”,向软件测试领域的“歪理邪说”宣战

图一  测试左移

上面这张图描述了测试左移的基本原理。即软件研发生命周期中的缺陷大部分是在编码过程中引入的,但是发现这些缺陷通常是在编码之后才逐步的发现出来。如果在编码过程中发现和修复缺陷的成本是1X,那发布给用户后,则发现缺陷和修复的成本会增长为640X。这也就引出了,如果我们提早做测试工作即“测试左移”,则发现或修复缺陷的成本会显著的降低。这也就是“测试左移”的理论基础。

如果你足够细心,这张网络流传的图还有个问题,即它默认缺陷的注入是从编码开始的,不过真实的情况只要有人开始参与了研发工作(如需求分析,设计等),就势必会开始注入缺陷,在这里我们就不累述了。

需要注意的是,最早开始说的“测试左移”这个概念是指测试工作要提前做,而不是特指测试工程师“左移”即全职测试工程师从编码阶段介入,这两者是有区别的!区别我们放到后面再阐述。

“测试左移”虽然提出时间不长,但这是个新概念吗?

软件工程领域最著名的模型毫无疑问是瀑布模型:

大家所熟悉的软件工程瀑布模型(waterfall model)概念,起源于 Winston Royce 发表于 1970 年的著名文章 "Managing the Developmentof Large Software Systems" (Proc. Westcon, IEEE CS Press, 1970, pp.328-339)。

 

炮轰“测试左移”,向软件测试领域的“歪理邪说”宣战

图二:瀑布模型

在我看来,所谓的“测试左移”正是在弥补瀑布模型的不足,即不要让测试工作只成为交付前的最后且唯一的质量保障手段,应该往前提,需要贯穿于整个软件研发生命周期中。

但是请注意,瀑布模型是1970年提出的,距今已经有50多年了,这么大的一个问题,怎么会几年前才给出个答案?

经典的V模型早把这件事情说完了!

V模型是由Paul Rook在1980年率先提出的,在1990年出现在英国国家计算中心的出版物中,它是对瀑布模型的一种改进。

炮轰“测试左移”,向软件测试领域的“歪理邪说”宣战

图三:V模型

在这里我不想解释V模型,有兴趣可以在网络上自行查询。

我想说的是,测试工作从需求开始,贯穿于整个软件研发周期是40年前就提出来的,这压根就不是啥新概念,如果你最近才知道那是你的问题!

那为什么近期换了个说法,又提出了“测试左移” ?

测试左移一词(shift-left testing)最早出现在Arthur Hicken的博客里,在他的博客中提到了对测试左移的看法。

炮轰“测试左移”,向软件测试领域的“歪理邪说”宣战

图四:最早谈到“测试左移”

原文可以访问这个地址:https://www.stickyminds.com/article/shift-left-approach-software-testing

但是这篇文章发布时间“测试左移”在2018年,比国内开始谈论的时间晚,有可能这个地址并不是首发地址,但并不影响我们的讨论。

从字面意义上看,“测试左移”更多的是强调开发工程师应该在软件研发生命周期内尽早的验证自己代码的正确性。注意是开发工程师自己测试自己的代码

在敏捷和持续交付的场景下,这个说法一点问题都没有,任何一个工程化的软件研发模型都在强调尽早验证和确认(这就是著名的V&V模型),最早可以追溯到40年前的V模型。

那为什么又开始强调“测试左移”那?很简单,一直没做呗!没做什么那?比如:单元测试,持续集成,单功能点验证等。注意以上这些测试,最合适的执行的人员是开发工程师本人。

为什么一直不按照要求做那?除了怕麻烦,对交付质量要求低,后续还可以让测试工程师代劳还能有什么原因?这也是在敏捷活动中,一直在推动开发人员自测,对自己代码质量负责,进行TDD实践等的核心原因!

综上所述,最开始提出“测试左移”的本意只是再次强调开发工程师应该自己做单元测试,对自己的代码负责,这是个老生常谈的话题。新的名词的出现,只是为了让开发工程师再次重视起来!

那炮轰“测试左移”,到底炮轰的是什么?

截止到现在,我们并没有发现“测试左移”的提法有什么问题,虽然“测试左移”本质上只不过重新发明了个名词,换汤不换药 。

可事实上并没有这么简单。

“测试左移”这个提法朗朗上口,随着时间的推移,“测试左移”被曲解成“测试工程师左移”,即测试工程师应该全部变为测试开发工程师,需要具备优异的开发技能,参与到单元测试,集成测试的环节中,或者说直接取代开发工程师来进行代码逻辑和接口的测试,通过编写代码测试代码。

更有甚者甚至鼓吹,今后将不再需要不懂代码的测试工程师,不会编码的测试工程师将全部失业,不会有未来,手工测试终将被代码测试代码取代。媒体广告中充斥着测试开发工程师,全栈测试工程师的宣传,这一氛围让手工测试工程师感觉低人一等,逐步的被边缘化,一夜之间仿佛软件测试工作不谈代码,不谈自动化就是政治不正确,就是被行业抛弃的角色。

上一页123下一页


留言