测试质量保障的影响因素

2022-09-14   出处: CKL的思考空间  作/译者:CKL的思考

8月13日应邀在天津做了一场质量保障相关的分享,主题是《看长远 顾眼前——测试活动的理想与现实》,其中关于测试质量的保障因素,自己做了个简单的总结,形成了如下图所示的公式,本文做个详细的梳理,欢迎探讨。

01 质量意识

首先,所有的测试活动都是由人开展的,人的因素应该第一时间被重视。测试人员对自己的定位,每个人自己的质量意识是非常重要的,如果你没有很好的质量意识,那么在遇到问题时,可能就轻易放过,或者浮于表面现象。

如果测试人员对测试的定位仅在于依据测试用例做简单的测试执行,当遇到问题时,就直接交由开发处理,自己不做相关的定位和分析,遇到比较复杂的,难以测到的问题,就放弃努力,给自己找借口。比如自己薪资就那么点,因为能力有限等等。在这种环境下,你很难去做质量保障的事。

如果测试员有以下认知:从自己手中出去的产品,要有最低的质量保证。那么出现问题后,能够及时反思,寻找解决办法,总结经验教训,努力提升自己。真正把测试当做职业来对待,想到办法解决或者规避同类问题的再次发生,或者通过更好的实践方式,提前预防问题的发生,那么质量保障就会得到很好的实践。

02 精业务

对于被测系统的业务逻辑,需要有很深了解,才能更好地开展测试活动。不能仅仅停留在页面操作上,知道被测系统,什么是核心功能,什么是辅助功能,哪些业务是不能出错的,哪些业务与周边哪些系统有千丝万缕的联系,能够基于业务流程、数据流程来做测试用例的设计。

同时,需要具备一些探索式测试的能力。能够贴近用户,基于用户的视角进行测试,关注功能点的实际业务价值,从客户的角度评估软件的实际工作方式。它更注重的是「思考」和「学习」,不断地发现新的问题。

03 懂技术

伴随着软件复杂度的提升,功能测试已无法满足日常的测试要求了。在很多场景下,需要测试人员能够开发一些小工具来帮助自己从有序的、重复的活动中释放出来。比如一些常规的造数、验证等。还有就是自动化测试相关的内容,也需要我们对代码能力有一些了解。

代码能力现在基本上会成为测试人员的必备技能,可能在深度上无法与开发相对比。但是基础的使用、基本的框架和常见的技术栈,都需要去了解和学习。日常测试内部的一些工具研发,还是要能够胜任。在一些专项测试领域,测试人员应该要能够做到对框架十分的了解,比如在接口测试层面,Junit、Pytest等常见的框架需要知道他们的现实原理,能够进行简单的二次开发等等。

04 会架构

除了懂技术外,为什么还要会架构呢?因为现在的企业级产品,基本上都会拆成若干个,基于几十个微服务。在这种情况下,如果你不懂架构,不了解这些服务或者组件的特性、通信方式、适用场景,你就很难发现一些深层次的问题。对于被测试系统的技术架构,需要每个测试人员都能够了解并画出来,这样在测试用例设计的时候,也会有更好的针对性。

同时,如果你走上了测试开发的岗位,那么必然会涉及框架或者平台的研发,这个时候,更需要你有一定的架构能力,去做一些技术选型和框架选择。从更高的层面去把控平台的技术特点。

05 资源限制

现在更多的人都会把精力放在以上几点,去做得更好,做得更深。但是从团队的角度上来看,我们还有一个不可忽略的节点,就是团队的资源限制。这是一个非常重要的影响因素。不同的团队有不同的背景,不一样的技术能力和沉淀。所以没有所谓的最佳实践,只有适合自己团队的最好实践。

当我们想要引入一些业内优秀的实践时,需要结果团队的资源,不要成为“先烈”(引入不匹配团队能力的实践,然后半路失败,成为牺牲品),而应该成为“先驱”(指导团队逐步落地实践,改进真实的痛点,引领团队前进)。在考虑团队资源限制时,可以从以下5个点来展开思考。

06 小结

做个小结:从团队的角度来看,我们希望团队的成员有更好的质量意识,这样在面对问题时,才能有更好的心态去解决问题。需要提升团队成员个人的业务熟悉度,培养他们一定的代码能力,在日常的工作中不断锤炼。同时扩大团队成员的技术视野,从全局来关注研发质量。但是,也不能忽视团队的现状及基础,因地制宜,因时制宜。盲目追求不适合团队当下现状的技术,会让自己成为“先烈”。


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
130° /1309 人阅读/0 条评论 发表评论

登录 后发表评论