如何让软件测试人员发挥最大价值

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/thomashtq/article/details/44852077

引言

对于软件测试员(有的公司叫QA或质量控制员)而言,在不同的公司文化或体制下,往往对自己的职责或定位都会存在很大的差异,导致软件测试员,甚至是公司管理员都存在疑惑: 软件测试员是否真的有存在的必要?如何才能发挥他们的最大价值? 


软件测试的目的是什么

什么是软件测试的目的?问题不是很简单吗?但是,我相信仍然有不少人都不一定能够答对。做事没有目标,就会像无头的苍蝇,到处乱撞。船在海中行驶,不能没有灯塔(现在或许有导航仪了,^_^),软件测试,也不能没有目标。对于软件测试员,你执行测试的任务,要达到什么目标?对于管理者,你招收软件测试员,用他们来干什么?要他们发挥什么价值?

下面就是软件测试的目标层次,看你达到了哪层?

第一层:软件测试的目标就是发现软件产品是否存在bug(缺陷或错误)。

第二层:软件测试的目标就是检验软件产品是否满足最终用户需求。

第三层:软件测试的目标是保证软件产品如期按需按质交付,保证产品的商业成功,获取最大利润。

下面我简单分析下各层次的状况。

如果你在第一层,你应该是初入测试行业的菜鸟,不错,就是菜鸟,不管你是否乐意接受。软件测试不仅是发现错误,还有用户需求(包括行业或操作惯例等隐性需求,例如默认 ctrl + c 是复制,若你的文本编辑器非要用它实现关闭程序,那只能留着自己用了)

如果你在第二层,应该在测试行业工作了几年,知道站在用户的角度去验证产品了。保证产品能够满足用户需求,离成功已经不远了,作为测试员,你也已经尽力了。

如果在第三层,你已经跳出了测试员的束缚,能够用管理者的眼光来审视软件测试,至少有几年工作经验或者管理者思维了。这个层次,测试已非测试,测试和开发不分彼此,都是为了产品的商业成功而努力。


软件测试的方法策略是什么

这个就没有统一的答案了,具体问题具体分析,没有放之四海而皆准的银弹。不同的公司(资源,人力,物力,财力等),不同的文化(保守,进取,激进,诚信,严谨,虚伪,欺诈等),不同的产品(移动嵌入式,服务器端,Web前端,桌面应用,单用户,多用户等),不同的产品阶段(预研调研阶段,需求阶段,开发阶段,后期收尾阶段,维护阶段等),所使用的测试方法策略都是不一样的。这么多因素组合在一起,你就知道为何同样是做测试,换个公司或者部门,感觉完全颠覆了你积累的“测试观”,这个是正常现象,如果都是千篇一律,那才怪呢!

但是话又说回来,难道那么多因素,我们就没有方法可循,没有准则可依了吗?凡事都有方法,都有规律可循,以下是我总结的几条经验,仅供大家参考,不当之处,敬请批评指正,欢迎砖头和大棒。

1. 引入自动化测试:对于服务器端要求稳定性高,软件生命周期长,软件需求变化不大,测试用例巨大,操作繁琐易错等场景,引入自动化测试是明智之举,绝对是“磨刀不误砍柴工”。有些公司领导抠门,认为自动化测试开发周期长,自动化测试人员薪资要求高,不舍得投入人力,财力和时间, 只顾眼前利益看眼前成果,匆忙让手工测试占主导。当后续随着测试用例的增加,执行周期越来越长,想搞自动化测试,已经来不及了!

2. 引入持续集成体系:对于采用敏捷开发的团队,持续集成必不可少!甚至可以说,持续集成做到什么程度,敏捷开发的成功就是它的程度。试想一下,若无持续集成,每天提交编译的代码,谁能保证能够运行正常?

有些团队也有持续集成,引入一些工具(Jenkins, CruiseControl, Appache Continuum, TeamCity等),每天能checkin,每天出个DailyBuild,就以为是持续集成了。他们往往忽略了最后一步,也是最重要的一步,那就是持续集成里的自动化测试步骤。可以毫不夸张的说,持续集成的自动化测试是否成功,决定了敏捷团队的敏捷开发是否成功,决定了产品是否能够如期按质按需交付,决定了产品是否能够如决策者预期那样,占领市场先机,取得商业成功。

3. 产品信息要公开明确:此处的产品信息包括产品需求(User Story,性能要求,环境要求,兼容性等),发布计划(包含周期,里程碑,RC,GA等时间点),测试资源(人力,时间,设备等)。有些公司为了所谓的保密,产品需求不给测试人员看(甚至普通开发人员都没权看),导致最终的产品不能满足用户需要,这种情况你还真不能怨测试人员。信息公开明确,便于制定计划,知道哪些测试点,需要多少时间和人力,统一协作(这也是团队精神的体现啊),上下齐心,才能最大限度地保证产品成功。

4. 开发与测试本不分彼此:开发与测试人员,根本不是矛盾和敌对的团队,而是相互依存分工不同的一个团队整体。如果开发与测试团队矛盾重重,一般都是体制奖罚的问题(例如以缺陷数来考核测试和开发的绩效,发现bug多,测试的功劳,开发的污点,反之亦然。),需要管理者深思变革考核机制。纯粹以代码行数,制造和发现的bug数或严重度来考核,真的是很失公允的考核方式,而且会造成开发和测试的矛盾,影响团队的团结。最佳的考核,应该是以项目是否成功来同时考核开发和测试,与公司其他产品比较考核,让大家荣辱与共,大家就团结了(局部团结,有可能会造成所谓的”部门墙“,但总比内讧强很多了)。

5.手工测试和自动化测试相辅相成: 手工测试和自动化测试,就像开发和测试,鱼和水一样,不可分离,相辅相成,才能达到最优效果。


手工测试和自动化测试的关系

对手工测试的误解

一提到手工测试,推崇自动化测试的人员,肯定会露出鄙视的眼神,对手工测试不屑一顾。这种认识是错误的,真正发现缺陷,保证产品质量的过程,手工测试功不可没。就算你是在写自动化测试的case,难道你不需要手动调试一下自动化用例?在调试的过程中,要么发现了自动化测试用例存在问题(或者脚本存在问题),要么发现产品不符合要求(软件缺陷),这个过程,就是手工测试的过程。另外,对于UI布局,视觉感观,音视频同步等QoS,自动化测试是很难发现问题或不易实现的。

对自动化测试的误解

对于自动化测试,有人爱有人恨。有人认为自动化测试是万能的,什么都要实现自动化测试(UI布局,视觉感观等);有人认为自动化耗时费力,写自动化的功夫,手工测试都已经做完好几遍了。这些认识都是片面的。自动化测试不是万能的,但没有自动化测试,是万万不能的!对于长时间的压力测试,重复成百上千遍的测试,自动化测试的优势就明显了;但是对于只是UI界面变化很快或者只是一次性测试的场景,还要进行UI界面录制或编写自动化用例,就得不偿失了。

总之,手工测试和自动化测试,要把握一个度,因地制宜,根据产品的特性等方面,进行综合规划,才能达到良好的效果。手工测试是为了发现bug和验证是否满足用户需求,用户体验是否良好;自动化测试是为了回归验证,或者弥补手工测试无法胜任的工作(成千上万的并发操作,持续7*24小时操作,大容量和吞吐量测试,低时延验证等)。两者各有所长,不能顾此失彼,有个微妙的平衡关系,就看管理者如何把握了。


测试人员与管理者的关系

这里的管理者,指测试组长,测试经理,产品经理,公司总裁等能够支配或影响测试人员的管理者。若管理者制定以发现bug数为重要指标,大家就会拼命发现bug,甚至不会放过任何错别字。别高兴太早,这有可能造成拣了芝麻丢了西瓜的局面。既然以数量为指标,估计没人愿意去发现长时间运行造成的内存泄露问题,大并发量造成的响应延迟或拒绝服务等缺陷,因为这些bug发现费时费力,还不如提提错别字或者UI布局来得实在。

所以,要想最大限度地发挥测试人员的价值,管理者提倡什么,大家就会做什么。作为管理者,应当提倡大家创新,改进流程,提高效率,让大家皆大欢喜,而不是让大家每天苦着脸麻木机械地执行测试用例,活干不完就要求大家没日没夜地加班。如果是那样的话,作为管理者,你是在扼杀人才,浪费公司资源,而且你将会面临大量员工流失的问题,最后导致无人干活,进行恶性循环。

作为测试人员,特别是有思想有抱负的测试人员,无论面对什么局面,你在投入执行测试任务之前,一定要想想能否通过开发工具来减少重复的劳动,磨刀不误砍柴工。哪怕一条case提高一秒,100条case也能够提高100秒,你就可以少加班100秒,减少电费100秒,自己支配的生命多了100秒,日复一日的话,又节省多少呢?想想吧,多划算啊^_^

小结

软件测试,不是凡人眼中的”没啥技术含量“,它是软件工程中的一部分,不可或缺。没有万能的软件测试方法,只有最合适自身的测试策略和手段。无论采用什么方式方法,别忘了我们的最终目标:取得产品的商业成功!软件产品在商业上不成功,神马流行的高大上技术(云计算,机器视觉,人工智能,大数据分析等等)都是浮云,当然喽,纯粹搞科研的不在此讨论范围。


阅读更多

没有更多推荐了,返回首页