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

第五点,请别跟我谈敏捷,就这件事情上来说没什么区别。开发人员必须完成自己的测试工作,请“开发右移”。

第六点,所谓的测试工程师的“测试左移”是提高了质量还是降低了质量?

短期看似提高(因为以前没人做的事情有人做了),但长期稳步下降(因为质量的第一责任人开发工程师放弃了这部分工作)。

谁的职责就是谁的职责!可以协助、教,但是绝不能替代!(所谓的教就是敏捷中的测试教练的工作)。

贯穿于全生命周期的软件测试,不意味着全生命周期的软件测试工作均由全职测试工程师完成,不同角色应该完成各自意义上的测试工作。

请诸位测试工程师充分的意识到:软件测试工程师是为质量服务,不是为软件开发工程师服务,具体的任何一项测试工作都是手段,你的目标是建立一个集合所有角色的质量保证或者说测试体系。所有角色分工协作,才能共同有效的保证质量。

醒醒吧:软件测试和软件开发处理的问题不一样,不要自怨自艾!到底是测试做的不好,水平太低,还是你理解的测试压根就不对?

用正确测试理念武装起来的,硬气的测试工程师对企业才有价值!

放弃能效比谈质量都是耍流氓

我们前面分析了大量开发工程师应该保证自己代码质量的原因。可能有人会问,你说开发人员自测自己的代码,保证单功能点的正确性姑且算你正确。但是“测试左移”说的是提早测试,这个提早测试并不唯一指单元测试、集成测试,还包括对需求的测试啊!“测试左移”泛指专业的测试工程师应该从需求阶段开始介入,这总不会有问题吧?如果没有问题,怎么能说“测试左移”或者说“测试工程师左移”是伪概念那?

这个问题很好,所以我放到最后讨论这个话题。先说一下我的结论,全职测试工程师从需求开始介入,可以认为是测试工程师左移的一个好的实践,但是不是一个所有企业都普遍适用的最佳实践那?我看未必!

为了说清楚这个话题,我们从如下几点加以说明:

首先,我们要区分测试工作和全职测试工程师的工作,测试工作广义上指验证和确认工作,可能由专职的测试工程师完成,也可能由团队中更合适的角色来完成。具体由谁来完成,需要组织综合考虑:技能适配性、沟通成本、职业发展、效率最优、成本最低等制约要素。

下面我们来讨论“测试工程师从需求阶段介入”是不是一个好的实践。

如果测试工程师从需求阶段介入,对测试工程师的技能有没有特殊要求那?答案是肯定的,当然有!

第一、在需求阶段介入的测试工程师要对业务非常熟悉,至少是个业务专家,对业务的理解不能弱于需求分析师,否则根本没有办法进行对等的交流。

第二、在需求阶段介入的测试工程师要对需求文档的书写技能和语言逻辑很清楚,这样才能参与到需求的获取和评审工作中来。

第三、在需求阶段介入的测试工程师要有很强的沟通技能,这个阶段的工作很多是从沟通交流中切入的。

第四、在需求阶段介入的测试工程师要有很强的测试分析和设计能力,因为这就是他此时介入的分内工作。

综上所述,在需求阶段介入的测试工程师是整个测试团队中核心中的核心!

那在需求阶段介入的测试工程师在这个阶段具体的产出物是什么那?

如果在需求评审之前介入的话,老实说,没有什么硬性的产出物,更多的是提前对系统需求进行了解。提出后续测试工作要点和组织方式的规划,由于需求文档也没有完全定稿,所以当前所有的工作都存在被推翻的可能性。

如果在需求评审中或需求评审通过后介入的话,更多的是作为需求评审人员参与需求评审工作,综合需求和其它文档等,进行测试的分析和设计,这里是有明确产出物的。但是请一定注意,测试人员如果参与需求评审工作,你首先是个业务专家,可以为需求评审贡献一份绵薄之力,其次你才是测试工程师,从系统的可测试性思考需求的问题。千万不要搞反了!需求工作的第一责任人是需求分析师,切记!

综上所述,如果作为质量的负责人,你应该如何选择?让测试工程师从需求评审前,评审中,评审后那个阶段介入更合理那?

这里并没有唯一或者最佳实践,你要综合考虑成本,环境,技术,风险,投入产出比等制约条件,综合考虑。

我的建议是:最早评审完成后介入,或者推迟到系统测试开始之前介入,主要是从投入产出比的角度考虑。当然,每个组织对质量的期望是不同的,需要按照自己的实际质量目标进行综合考虑。

就这个话题来说,我们谈论的范围并没有超过几十年前V模型涵盖的内容,如果说这就是最“先进”的“测试左移”理念,我表示不服!

总结一下:放弃成本谈质量,就是耍流氓!合理的团队协作模型,让组织效率整体提升,过程质量、产品质量双提高才应该是追求的目标!

对在软件测试圈内“贩卖焦虑”说不!

软件测试领域是个专业的领域,作为这个行业的从业者,我们应该系统化我们的测试体系,用正确的测试理念武装自己。

我们构建的是一个基于风险,基于概率思维的质量评估体系,技术手段是为测试目标服务的。

专业的软件测试不能脱离整体的覆盖率谈测试技术。

小酋观点:

这是一篇值得深思的好文~

不管开发也好,测试也好,都应为最终软件质量负责。

测试开发不能解决一切事情,业务功能测试也必然会长存,测试开发比重应根据公司研发的规模 和实际情况进行取舍。

测试员左移进单元测试确实有点歪了,这应该是开发员对软件质量负责的关键的一项工作。

测试开发需要更好的定义,如具有扎实软件测试基础知识的开发人员,目的是为了服务组织的测试的效率和质量而服务。而不是随便招个开发员进来,不懂测试而为测试服务,最终研发的工具或脚本存有一堆缺陷,用带有大量缺陷的东西来服务于测试。

-- End --

文末寄语:  真正有生命力的思想不会被体系的废墟掩埋,一旦除去体系的虚饰,它们反以更加纯粹的面貌出现在天空下,显示出它们与阳光、土地、生命的坚实联系,在我们心中唤起亲切的回响。

源自公众号 领测软件测试网

上一页123下一页


留言