你与高级测试间就差这3个软实力
转自:
正文
前天晚上我面试了一位6年测试经验的功能测试。在面试过程中,我问了一个问题:她现在相比3年前的自己有什么提升,或者说应该有什么提升?她回答了两点:1.掌握更全面的测试技术。2.测试管理经验有了提升。虽然这是她的答案,但是并不是我想听到的,我更想问她的是,做了这么多年的功能测试,相比一个两三年,已经处于熟手阶段的功能测试,到底有能什么提升。那么接下来,我就谈谈我自己眼中的高级功能测试与中级功能测(熟手)的区别。 ps.高级,中级,只是泛指,与公司内岗位级别没有挂钩。
测试规范
高级功能测试应当深刻理解测试规范。
一个中级(熟手),他经过几年的功能测试训练,肯定已经熟练掌握了测试规范。高级的区别就在于他是否洞悉了这些规范的背后原理。中级知其然就够了,但是高级的要求却是要求知其所以然。
一个规范的制订肯定有它背后的用意,很多人非常多年只是习惯性得去执行,却不曾去思考,这么做是否合理。一个合格的测试应该有怀疑精神,时常去思考,这么做是否是对的,即使这个规范已经执行了很多年。只有不断去思考怀疑,才能真正洞悉背后的运行原理,接下来才能对测试规范进行进一步的改进。每个团队的测试规范基本是针对所有测试项目统一制订的。每个项目有它的差异性,那么理论上来说,为了达到最大的效率,项目本身还能够量身定制一套测试规范,从而达到测试生产力的最高。但是因为团队流程制度的关系,是不可能制订这么细致,并且经常微调规范。高级测试应该能够自己本身进行快速微调测试规范,从而达到生产力上的最优。
建立模型
高级应当比中级站在站在更高的业务高度,以及建立更加精准的业务模型和用户模型。
1. 业务模型
测试人员都擅长于细节,但是太多人往往沉迷于细节或者陷在细节里出不来。高级功能测试应该能够从细节里跳出来,站在业务的高度往下看:什么是核心的业务,什么是重要的业务,什么是次要的业务。产品设计了产品原型,他为什么是设计成这个样子,而不是另外一个样子。各个业务模块之间的耦合关系是什么。世上几乎不存在完全测试的项目,多多少少总是存在资源不足,某些功能测试不到位的情况。只有站在一定的业务高度,建立了准确的业务模型,才能准确判断出测试资源分配的倾向。用最少的资源保障最大的交付价值。bug永远是存在的,很多bug在软件被所有用户停止使用前都未被发现,测试保障用户使用软件的质量即可。
2. 用户模型
很多项目,测试与用户接触的比较少,更多的是产品去对接用户。但是测试是保障用户的质量,功能测试基本上就是模拟用户在操作。那么用户看重的是什么功能?他们的操作习惯是什么?每个人心中必须有用户模型,高级测试应该比中级测试更准确,更快得建立模型。等准确到一定程度,还要针对不同用户群建立不同的模型。
研发流程中的角色
在研发流程中,高级测试要能够作为产品和项目的部分备胎角色,同时与低水平队友合作时也能保障工作顺利衔接。
测试用例的设计的方法,相对还是很简单的,一个大学生培训几天就能合格。再加上业务知识,所以测试的门槛一直很低。那么测试仅仅只是执行测试工作就够了吗?如果想永远做个中级测试,我想这应该够了。但是我们知道,软件研发是一个分工协作的过程,仅仅是研发团队,就包含了非常多的角色,项目,产品,UI,开发,测试,运维等,大型研发团队还会有更多的角色分工。 这些角色之间,信息的流转有两个核心结点,项目和测试。项目是着眼于一定高度看项目运行,测试应该是着眼于细节看项目运行。在进入测试环节之前,大家基本是着眼于核心功能,对细节考虑会比较少。但是细节不重要吗?最后出问题多的地方往往是功能的细节。如果能够把在细节上的问题,在进入测试之前就大量解决,那对软件质量的提升以及研发成本的降低都是是巨大的。产品设计出的原型肯定是从上往下设计,类似于写思维导图。细节不是他们最看重的地方,这个时候,高级测试就应该能够对细节进行推敲,诊断出设计不合理的地方。
中级测试要能够熟练得实现与团队各个成员的配合,并且作为团队一员把信息积极准确得流转到项目处。如果发现了隐患风险,要把这些风险及时发出预警。团队配合肯定存在模糊地带,团队成员的技能也经常良莠不齐。跟神一样的队友在一起时,把事情做好不是本事。遇到猪一样的队友,队友事情做得很烂,高级测试应该也能顺利实现衔接。尤其是工作配合的模糊地带,高级测试应该能在对方模糊地带工作没做好的情况下进行补位,实现冗余保障,保证项目顺利进行。
很多小型团队没有专职的项目经理,这个时候,测试作为信息流转的核心结点之一,应该能起到部分项目经理的监督职责,高级测试的意义更加凸显。
总结:
高级测试更理解测试流程。
高级更懂业务模型。
高级测试主动补位。