到底是什么阻碍了产品质量的提升?
我见过一个大功能只有 3 行需求描述,我听过项目经理讲测试参加需求会议只是为了知情
开发讨论详细设计从来没有通知过我,甚至没有见到过详细设计文档等跟开发相关的文档
我听过测试组长说有问题就提,原因让开发自己找去
我还见过开发手把手教接口测试然后测试组长说自动化没什么用
我见过开发打包新版本细节做了修改却不吱声
我见过测试环境被信息部门控制不允许发请求
我还见过每年招聘几十个开发名额,测试名额只有两个还是要求极低的
我不知道是什么阻碍了产品质量的提升,可能是我能力不够吧。
哇咔咔
扎心了老铁。
有句话,我觉得挺贴切的,拿着种菜的钱,操着卖白粉的心。
不过话说回来,入了行,当然是遇到问题就想办法解决啊。一味吐槽也不是办法。
阻碍前进提升的就是人心或人的能力,但其实还是人
我见过一个大功能只有 3 行需求描述,我听过项目经理讲测试参加需求会议只是为了知情
开发讨论详细设计从来没有通知过我,甚至没有见到过详细设计文档等跟开发相关的文档
需求管理和项目管理问题,这个问题推动解决是很难的,症结在别处。更适合抓反面教材来施加影响力。这个过程痛苦的不止是测试,还有研发和 PM,可以多争取外部力量公共推动。你个人是没法推动的。
我听过测试组长说有问题就提,原因让开发自己找去
我还见过开发手把手教接口测试然后测试组长说自动化没什么用
我还见过每年招聘几十个开发名额,测试名额只有两个还是要求极低的
测试能力建设问题,这是典型的破罐子破摔的风格。如果人员能力有问题,这个时候就不能做全面的质量建设了,而是选择微改进的方案。先选择一个有价值的方向把事情做好。比如看看目前的 bug 和故障根源是什么,做什么样的测试才能用最少的投入换来最大的汇报从而更好的保证质量。先从一个点做起,有亮点了再申请更多的资源。领导们见到了效果自然也会明白 “一个诸葛亮多数时候都会比三个臭皮匠要强”
我见过开发打包新版本细节做了修改却不吱声
打包流程要自动化,组织人员对新版本做 code diff 分析影响范围和测试范围。自己也可以写个小脚本去比对版本之间的代码变化,都有 commit 在,很容易自动化发现这类问题,然后再找他们 “算账”。
我见过测试环境被信息部门控制不允许发请求
协商沟通推动解决,用其他公司的现状做例证。
当然在这样的环境里发展的确困难重重,建议还是多跟同行交流学习经验、尽力而为推动解决问题。实在改变不了环境再考虑换环境。
一个人的可贵,不仅是他的能力,还包括他的精神面貌。比如最近很火的三色案,我们改变不了什么,但是持续努力的去解决问题,最后就会有回报的。
我本以为换个大点的公司会好点,没想到还是一样的情况。。。
感谢大神指点方向
其实有些症结是整个团队对质量体系认知不足,以前提出来过,决策层不听。。。
还有一个故事是我们这测试看不到代码的,之前申请 SVN 代码权限,被领导层以 “不安全” 为由给否了。
看到了问题,提出了方案。
你努力过了,但是发现大家的价值观不一样。
如果发生在我身上的话,应该会考虑下如何炒掉老板,找一群志同道合的人吧~
见的多了就不奇怪了,还有更奇葩的。(我见过有个小公司的还把初中毕业学历、社会上浪迹多年的房产中介小哥的招进去做测试,美其名曰节省成本)
要么改变他们,如果不能,就换 1 个更好的平台。
关于测试组长、开发组长,每个公司都有这个职务但能力又参差不齐,也许是公司无人可用,也许是他混的经验较多,大多的时候,互联网的公司看重的是能解决技术问题的人,而忽略了个人素质本身的问题。恰恰在中国,人的问题比技术问题更严重。
QA 的角色属性是天然要求自带控场技能的。质量保证本质上就是持续改进、优化现有环境的过程,如果测试扮演的角色是被环境所同化的附属品,那一定不合格
我们在改变环境过程中面临的各类障碍,其根源无非人和事。
我的理解是:事情层面的困难,往往都能找到行之有效的解决办法。而人的层面,其核心往往都在认知高度和观念态度上,如果我们通过各种努力,仍然无法逾越障碍,就别再继续纠结沉没成本了,抱怨过后,重新给自己一个选择环境的机会吧。
这是一个屁股决定脑袋的典型问题。
所谓质量意识,实际跟公司所做的产品形态衍生出来所谓的质量文化息息相关,质量问题引发的成本和代价越大,这个公司越会重视质量。反之,就不那么重视。资本家嘛,总是希望花一块钱产出十块钱,或者避免 100 元的损失。
传统企业,如汽车,白电,通信设备制造等对于质量要求是非常高的,其质量部门的话语权也是很大,有严格意义上的一票否决权,毕竟一旦出问题,会对企业造成直接的经济损失,乃至于对品牌价值产生重大打击。参考三星的电池爆炸事件和近期苹果漏洞事件。
然而互联网时代,很多产品出了质量问题并不会对企业产生直接的经济损失,或者说微乎其微,屁股决定脑袋,如果有 10 个 hc 预算,老板都愿意给资源到能够实际看到输出的工作岗位,而不是给到质量把控这种隐形成本上,反正出了 bug,再发布版本进行修复嘛,挺多大家一起加个班。除非你能告诉老板,质量每提升 10%,可以让 DAU 提升多少,带来多少看得到的收益,否则是很难说服老板给予支持的。当然还有比较腹黑的办法,就是让企业为此买单,有了痛才有得改。时机是非常重要的一件事。
再有一方面就是现在非常多的测试岗位从业者的不专业性,也是造成现在这个局面的非常大的原因,这个就不展开讲了。你有了能力,并且在真正适合的行业里面,才能真正赢得别人的尊重。