从毕业踏入软件测试行业,偶尔在测试报告中看到“线上 0 Bug”这个的字眼。不知道何时,这样的测试结果被当做了一种标杆,大家好像默默的在追求这种“0 Bug”的美好测试结果。无形中大家被带入了误区,认为专业的测试人员、全面的测试设计下不应该有Bug,只要有问题,那么就是测试的锅。
其实答案很明显,大家都知道测试是没有穷尽的,只要你愿意投入时间、人力去测试,总会发现大大小小的问题,但缺陷是会收敛的,前期我们可能每天发现20个缺陷,但随着测试的开展,每天发现的缺陷数量逐渐变少。如果缺陷也遵循二八原则,投入20%成本,发现80%的缺陷,那么剩下的80%的成本你是否会选择去发现那20%的问题呢?——视情况而定。
因此只有没有被发现的Bug,没有0 Bug。我们不需要去追求100%的完美结果,因为这是不存在的。
那么近乎完美的结果是什么?——线上没有问题被发现、被吐槽。被谁?——被用户发现。但随着用户使用次数、用户基数的增多,几乎不可能没有任何问题。
研发自测,凭啥 ?
进入测试行业,在参与的第一个项目的大迭代后,进行了一次缺陷分析,通过分析发现研发提测质量比较差,发现很多明显的重要、中等缺陷,占比30%。于是对研发提出了“自测”的要求,这是我第一次提这个词,虽然研发看到缺陷分析的数据后,也无话可说,只能去执行,但也能从脸上看出一丝丝的“凭啥?”。
其实,我也在想凭啥?测试人员不就是做测试嘛,研发人员不就是应该开发嘛,那么“研发自测”这个怎么界定测试范围呢?
如果说质量是一个平面,平面中存在一个圆圈,圆圈内就是研发人员自测、圆圈外就是测试人员测试,圆圈内做的是质量内建,在有限的范围(基本功能性)内建设质量,圆圈外做的是质量外建,在无限的范围(功能性、非功能性的广度、深度)内探索质量,这样来看,研发、测试共建质量,挺好。
现在,随着测试左移,也提出了测试人员通过测试技术帮助研发内建质量,比如自动化测试的左移。
技术推动质量保障?
特别是近几年,兴起了技术推动质量保障之风,我也乐死不疲的加入测试开发的队伍当中,但技术真的能保障质量吗?
先来看看我们使用技术做了些什么?,做了重复性高的测试用例的自动化;做了因为测试成本较大而没有时间每轮迭代都会覆盖的用例的自动化;做了测试数据构造、测试环境检测工具。
从上面来看,技术到底保障了什么?——效率。效率提升的背后有什么什么?——是我们将提升的效率的收益,是否投入到了测试外建(功能性、非功能性的广度、深度)当中。
产品质量的边界是什么?
作为一个测试人员,保障产品质量当之无愧,那么产品质量是什么,没有缺陷?
记得在2016年,第一次对产品进行线上用户行为分析,在此之前我们一直认为项目质量非常OK,因为线上缺陷少呀。
但分析结果直接颠覆三观,产品各功能模块用户使用次数严重不均衡,自己所测的模块用户使用次数占产品总用户数的20%... 原来线上缺陷少,还有另一种可能——用户使用的少。
那么,产品质量的边界是什么?很自然,绝不仅仅是线上缺陷数量。产品质量不是测试说的算,也不是研发说的算,而是用户说的算。产品质量好坏是用户综合体验的反馈,是否真正的满足用户需求,达到用户的使用目的,同时也是用户使用过程中,产品的功能性、非功能性没有对用户使用操作干扰,用户体验流畅、用户增长、留存等等。