你好,我是宝玉。从这一篇开始,我们将进入软件工程中的测试模块的学习。
说到软件测试,你一定不会陌生,尤其是如果你做开发相关岗位的话,一定是对测试又爱又恨,一方面测试从你的程序找出 Bug,然后你还要费心去修复;另一方面测试帮你发现 Bug,修复后能很好的提升质量。
正因为测试能发现软件中的质量问题,通过测试能有效提升软件质量,慢慢的大家就觉得软件测试能保障质量,所以测试要对质量负责。开发也会对测试产生依赖心理,很多功能模块实现后,就扔给测试人员去测试。
上线后,如果因为有测试漏测导致的 Bug,测试人员还要为质量问题背锅,受到责备。上面这样的场景到现在也还在很多软件项目中上演。但这对测试人员其实是不公平的。
因为软件开发是多个环节组成的,从最开始的需求,到后面的设计、开发,每个环节都可能会导致质量问题,而测试只能对已经开发完成的软件产品进行检测,并不能干预整个过程。
比如说测试是无法对开发写的代码直接测试的,只能基于软件功能去测试,也就是说对于代码的质量,测试人员其实是没有什么办法的。
那到底谁应该为产品质量负责呢?在回答这个问题之前,你不妨先思考一个更本质的问题:什么是软件产品质量?
我以前以为,软件质量就是由 Bug 数量、性能高低、安全性等指标决定的,现在看来这样划分其实并不全面。
因为不同的人对软件质量好坏的评判角度是不同的。比如对用户来说,更看重产品是不是满足需求,是不是美观好用;对开发来说,看重的是代码质量是不是高,是不是好维护;对于软件测试人员而言,看重的是 Bug 数量、安全、性能等指标;对于项目负责人,看重的是整个开发过程的质量,是不是成本可控、如期完成。
在这个问题上,我比较认同《The Three Aspects of Software Quality: Functional, Structural, and Process》这篇文章作者 David Chappell 的观点,他把软件质量分成了三个考量方面:功能、结构和流程。对于他提的“结构质量”,我认为定义为“代码质量”更贴切,也就是说,功能质量、代码质量和过程质量这三个方面组合在一起,很好地概括了软件质量。
所有的软件开发都是从一个想法开始的,用户需要一个软件,有人出钱,然后开发团队实施,把想法变成需求,需求变成设计,设计变成代码,代码变成软件。
最终用户得到是软件,体验的是软件的功能,功能的质量直接决定了产品的质量。
满足用户需求,是对功能质量最基础的要求。在这个基础上,Bug 数量、性能、UI/UX 都是很重要的质量指标。如果你的软件 Bug 太多、性能差,用户不会满意;界面难看,操作体验也很差,这些因素都决定了你产品的功能质量。
构成软件最重要的部分是代码,代码质量指的是实现软件功能的架构和代码的质量。代码的质量主要体现在以下这些方面:
代码的可维护性,也就是在不影响稳定性的前提下,是否能方便地添加或者修改现有的代码;
代码的可读性,代码是否容易理解,是否能快速上手;
代码的执行效率,代码执行效率直接影响了软件性能;
代码的安全性,是否有安全漏洞,安全性是代码质量很重要的一个指标;
代码的可测试性,代码是否能使用单元测试、集成测试进行测试验证。
虽然用户不能直接感知到代码,但是代码质量高低会直接影响功能质量,同时代码质量低也会影响后续的维护升级。
软件的开发离不开软件工程,离不开项目管理。软件开发过程的质量决定了你的项目是否能如期完成,开发成本是否在预算之内。
过程质量虽然也是用户不能直接感知的,但是过程质量会直接影响代码质量和功能质量,甚至是产品的成败。
以上就是软件质量的三个方面,软件质量从来不是单方面质量决定的,通常是几方面质量因素相互影响,共同决定的。
比如说改进流程,增加了自动化测试的覆盖,应用了持续集成,这样可以提高代码质量和功能质量。或者说对代码质量过于追求,又可能会影响过程质量,例如时间延期,成本超标。
在梳理清楚产品质量的问题后,我们就可以来讨论谁该为产品质量负责的话题了。
既然产品质量是由功能质量、代码质量和过程质量共同决定的,那么对产品质量负责,意味着要对这三方面共同负责。
在说到责任之前,我想补充一下权责对等的问题。责任和权力是需要对等的,比如说你让开发人员对软件开发过程负责,那么前提是他必须有权力去影响和控制开发过程,否则离开权力谈责任就是耍流氓了。
然后,我们再一起看看项目中的主要角色,谁最应该为产品质量负责?
软件测试,可以对功能质量负责,对软件产品进行测试验收,以确保产品满足功能需求,有好的功能质量。但是通常不能对代码质量和过程质量负责。
开发人员,可以对代码质量负责,也可以写测试代码,通过自动化的方式做功能测试,虽然还不能完全替代手工测试的作用,所以也可以算得上对功能质量负责。但开发人员通常对过程质量影响有限。
项目负责人,可以对过程质量负责,而且过程质量的水平高低,会间接影响代码质量和功能质量。但因为项目负责人不直接编码和测试,所以无法直接影响代码质量和功能质量。
所以综上,我觉得如果要排序的话,软件质量的首要负责人是项目负责人,其次是开发人员,然后才是软件测试。
虽然从权责的角度看,项目负责人是最应该对项目质量负责的,但是从效果来说,却是开发人员对项目质量负责最有利。
首先,开发人员是唯一能直接影响代码质量、能对代码质量负责的人。开发人员能更容易地找到代码中的 Bug,更容易通过架构设计、自动化测试代码等手段保证好代码质量,提升测试效率。
现在软件开发的发展趋势也是如此,软件测试的很大一部分手工测试工作已经被自动化代替。
所以很多公司就让开发负责产品质量,甚至都不设测试岗位,典型代表就是 Facebook。开发人员自己写代码实现功能,然后写自动化测试代码对功能进行测试,最后上线。这样不仅自己测试能保证功能的质量,又能通过自己写单元测试、集成测试来保证代码的质量。
当然,开发人员对功能质量负责,意味着必须在实现功能的同时,还要考虑如何去测试这个功能,这样让代码更具有可测试性,这就对开发人员的要求更高了。
就像 Facebook 强调的“Be there from start to ship”,就是让每个工程师能自始至终地负责产品。从想法到原型设计、到产品开发、上线和维护,全部是工程师自己完成。
我们不需要做到 Facebook 那样,从头到尾都一个人搞定,但至少,作为开发人员,我们可以对代码质量有更高要求,让项目有更多自动化代码的覆盖;可以在交付测试之前自己先测试一遍。
这样的话,开发就可以真正做到对代码质量和功能质量负责。如果你还想对过程质量也能负责,那么敏捷开发中一些理念是有可取之处的。
敏捷开发中强调的是:项目的所有人一起为产品质量负责,人人为产品质量负责。
但人人为质量负责,很容易变成一句口号而很难落实。就像三个和尚没水喝的故事里面那样,当质量变成每个人的责任时,就没有人真正为质量负责了。所以我们不只是要学习敏捷开发中的理念,还要学习它一些具体的方法。
只有真正在团队中建立了一种重视产品质量的文化,每个人才会确确实实地对质量负责。那么有哪些方法可以帮助团队建立这种“人人都重视产品质量”的文化呢?
首先,可以参考敏捷开发中的扁平化管理。在敏捷开发中没有项目经理,只有产品负责人,而产品负责人更多是充当一种服务型的角色。大家都很平等,也就是说每个人都有权力去影响到项目过程,实现权责对等,大家才会为过程质量负责。
其次,可以选择将团队拆小。敏捷开发中的团队规模都不大,大的开发团队拆分成了小的开发小组,每个组人数都不多。人数多的时候容易推诿扯皮,但如果人少,每个人就必须要承担更多的责任,这有助于形成人人重视产品质量的文化。
另外,也可以鼓励工种之间的融合,例如开发人员多写自动化测试代码;测试人员在开发人员写自动化测试时,提供帮助,例如设计测试用例。这样不只是局限于各自负责的质量领域,也同时关注其他质量领域。
最后就是制定相应的制度,鼓励大家重视质量。比如说:
每个 Sprint 都有项目回顾会议,每个人都可以针对质量提出有效的建议,最终将这些建议落到实处;
出现质量问题,不是推卸责任,而是分析原因,及时修复,避免以后出现类似问题。
要做到“人人为产品质量负责”,还是要像上面提到的一样,要落到行动而不是口号上,组织上扁平化、小型化,分工上打破岗位墙,制度上鼓励大家重视质量,才能真正建立重视产品质量的文化,一起把产品的质量提升上去。
今天我带你一起探讨了一个在软件项目中的常见问题:软件测试要为产品质量负责吗?
保证软件高质量,并非只是测试人员的责任。软件质量体现在功能质量、代码质量和过程质量这三个方面,对产品质量负责,也意味着要对这三方面共同负责。
软件测试,不能影响代码质量和过程质量,所以并不需要为产品质量负责,项目负责人能直接影响过程质量,也能间接影响代码质量和功能质量,应该为产品质量负责。对于开发人员而言,不应只是局限于对代码质量负责,还应该注意功能质量。
对产品质量,最理想的状态还是能做到人人都为产品质量负责,而达到这样的目标,还是需要建立一种重视质量的文化,每个人才会确确实实地对质量负责。