从对人负责的角度,重新理解软件测试

2021-03-29   出处:软件质量报道  作/译者:Test Ninja  

                                                                “从对人负责的角度,重新理解每一个职业”

                                                                “当一群人深陷在自己的社会分工中,

                                                                只会对事负责的时候,

                                                                总会有另一群人觉醒过来,

                                                                能跨越出自己的社会分工,

                                                                对人负责。

                                                                                            ——罗振宇,2021跨年演讲

        软件测试在一个项目中的确有很多事情要做,最基本的包括制定测试计划、编写测试用例、搭建测试环境、执行测试用例、报告测试结果等等。但是,软件测试的目的是为了对这些事负责吗

        人们通常认为,软件测试就是验证软件产品特性是否满足用户的需求,或者就是发现软件产品中的bug。这都没有错,是正向和逆向两种思维方式,互为补充,发现软件中的bug也是从用户角度出发,找到对用户产生负面影响的缺陷。这样来说,其实软件测试从根本上不是对产品负责,也不是对bug 负责,而是对用户负责。

        如果对事负责,你会花很多时间去读需求文档,根据文档编写测试用例;

        如果对人负责,你会花很多时间研究用户,分析产品的目标用户,观察用户的行为,研究用户的应用场景。

        如果对事负责,你会视用户故事卡片、需求文档为圣旨,把它们作为测试的依据;

        如果对人负责,你敢于质疑用户故事的描述、需求文档是否完善,是否正确,是否代表了用户真正的需求。

        如果对事负责,你会按部就班的执行测试用例,每天完成多少条测试用例,每周提报多少个有效的bug;

        如果对人负责,你会在测试中扮演产品的用户角色,从用户出发设计不同的用户场景进行测试。

软件测试到底是一个职业还是一个角色?

        子曰:君子不器,出自《论语·为政》,意思是君子心怀天下,不像器具那样,作用仅仅限于某一方面。人一旦成为器物就会很脆弱,因为器物是有形的,有形的东西用途就是固定的,一旦情况发生变化,这种器物没用了,就会被抛弃。因此,人要具备反脆弱的能力,就不能让自己局限于只能做一种事。

        在传统的瀑布式软件开发模式中,开发和测试被分成两个不同的阶段,开发人员和测试人员的职责泾渭分明,做开发的只管编写代码,做测试的只管找bug。因此,传统模式下的研发团队中,既有专门的开发部门,也有专门的测试部门。在这样的体制下,软件测试被当成一项职业,一个社会分工。但开发和测试好歹还在一个研发团队里,负责需求的产品市场部门往往独立在研发团队之外,产品部门、开发部门和测试部门之间都有厚厚的墙,需求从墙外扔过来,产品从墙内扔出去。产品经理、开发人员、测试人员、项目经理这些角色都被禁锢在各自的系统里,都成为了工具人,互相也不了解各自的业务领域。

        敏捷开发模式让这个情况开始转变,打破了开发、测试和产品之间的墙,倡导这三者之间的彻底融合,大家组成一个全职能的敏捷团队,软件测试不再只是测试人员的责任,开发人员也要做测试,测试人员也要参与需求分析,产品负责人也要参与软件测试特别是验收测试。可以说,在敏捷模式中,软件测试不再是一项职业,而变成一个团队中的角色。显然,这对人的要求更高,但也有助于掀翻软件测试人员职业发展的天花板,充分调动和发挥团队中每个个体的潜能。


                               研发组织从传统向敏捷演化(以Scrum为例,来自朱少民的《高效敏捷测试》专栏

我们是否常常困在自动化测试系统中?

        现在每个企业都有自己的自动化测试系统,在软件测试中引入测试自动化的目的当然是为了提高测试效率,提升产品或新的功能特性交付给用户的速度。但是,许多公司为了自动化而自动化,为了建测试平台而去建测试平台,重复造轮子的现象相当严重。作为测试开发人员,你是对自动化测试系统负责,还是对最终交付给用户的产品负责?是为了开发一个测试系统而开发,还是为了快速的向客户交付有价值的产品?

        如果困在自动化测试系统中,你会热衷于工具开发,重点关注的是开发一个功能强大的系统,你的目标是开展尽可能多的自动化测试。

        如果只把自动化测试作为手段,你会思考如何制定测试策略,什么样的测试采用什么样的测试方式,或者有时候采用手工测试也许效率更高?

        如果困在自动化测试系统中,你只会把手工测试用例“翻译”成自动化测试脚本,并不关心测试用例本身是否合理;

        如果只是把自动化测试作为手段,你会首先从业务出发,从满足用户质量要求的角度考虑测试覆盖率,先解决测什么的问题,然后再思考怎么测的问题。

我们是否常常困在测试流程里?

        从上个世纪后期到现在,软件测试经过几十年的发展,目前已经形成了完整的测试流程和体系。一开始没有流程的时候,大家都是摸索着前进,逐渐了形成了一套流程,又变得越来越重,传统的瀑布开发模式下的测试流程尤其如此,在此基础上,又发展出认证体系,比如TMMi认证。很多企业为了业绩和资质,全力以赴只为拿到认证。那么,我们到底是对测试流程负责,还是对流程中的自己负责?

        流程中必然包括针对软件测试的绩效系统,测试人员被要求一天执行多少条测试用例,一周提报多少个有效的bug。一套绩效体系被建立起来,这和要求外卖小哥多少分钟送达外卖很有几分相似。每个测试人员被困在绩效系统里,那么,他们是对绩效指标负责,还是对用户负责?一切的系统对我们来说,都只是工具,绩效看板让我们能够清楚的了解进度,计划和调整工作,但我们不是对绩效负责,而是对产品负责。

总结

        你还会困在这个软件测试的系统(方法、流程、工具)里吗?不,所有这一切,最终都是为了让用户满意,而这些只是工具。

        总体来说,传统的软件测试更重视流程,让人按照流程去做事,什么时候该做什么事,因此往往对事;而现代的敏捷测试更重视用户,因此往往对人。

        传统的软件测试构造出一个坚固的系统,把软件测试人员困在系统中,只能做测试流程中规定的测试人员该做的事,用固定思维来看待做事的人;而现代的敏捷测试坚定的要打破这个系统,不会把团队中的任何人固化在一个职业里,一个角色里,赋予个体更大的成长空间,鼓励个体的成长性思维和批判性思维。

        这代表了一种进步,但归根到底,能困住人的不是系统,而是人本身,你到底应该对事负责,还是对人负责呢?


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

太难  2021-03-31

mark


太难  2021-03-31

收获


登录 后发表评论