测试的最终产物是什么
https://mp.weixin.qq.com/s?__biz=MzkwNTI2NjAxMA==&mid=2247483961&idx=1&sn=95836c7b3b9135fb445a5d7d29bc04c9&chksm=c0fb140cf78c9d1af97a3325c2ffc18637d08e7d32278171c2716e110160206766f8eb03eae6&cur_album_id=1979310371207184387&scene=189#wechat_redirect
在Testerhome看到一个很有意思的问题,题目是:测试的产出到底是什么?“质量保证,或者产品优质,这些都只是结果,且单纯靠测试是肯定不行的,但是在日常的工作中,测试的产出到底是什么?”这是个很有意思的话题,对于测试的产出,不同人有不同的理解,大家也可以自己先想想。
聊聊个人的看法,总结起来就几个词:一个思维、一份报告、一点责任,努力精进。下面详细展开来说说。
01 一份思维
关于测试最终是否会消失,不认可的人群中有一个很鲜明的观点,就是让开发人员自测是件很不靠谱的事,自己给自己找问题,思维上的转变是很困难的。所以,测试人员在每个迭代或者版本中,第一个交付的,就是自己的测试思维,制定针对当前迭代特性内容的测试策略,通过不同方式的测试建模,输出一份高质量的测试用例,本质上,就是测试人员测试思维的体现,如果你仅仅是顺着开人员人的研发思路进行测试,又或者只是关注产品的需求文档,只进行简单的页面增删改查验证,那是远远不够的。只有你深入了解需求,了解需求的具体使用场景,结合自己的经验和能力,设计出高效的测试用例,才能体现你测试的专业性。
02、一份报告
测试报告是测试人员工作的总结,也是测试人员具体的价值体现。一份好的测试报告至少应当包含以下几点内容:
测试范围:你最终的测试范围是什么,覆盖了哪些功能点。哪些是原来迭代规划的,哪些是临时增加的,又有哪些转动了下个迭代中。这些都是需要明确出来的,看报告的人并不一定会全程参与到研发过程中,所以需要你的测试报告来体现真实的迭代内容是什么。
测试结论:从测试人员专业的角度,给出迭代的质量评估,是否达到了发布标准,是否可以发布,如果不能,说清楚原因。
测试风险:在测试过程中遇的考虑到的风险,上线后可能发生的风险,如果你知道,请明确出来,让团队各角色(研发、产品、部门负责人等)根据你的风险分析,一起来决定是否发布版本。
当然,测试报告不仅仅只包含以上内容,但是以上内容是看报告的人最注的内容,除此以外,还应该包含但不限于测试策略、人员投入、BUG分析(对研发团队很重要)、测试改进意见等等。
03、一点责任
作为测试人,经过自己测试过的内容,应该承担一份责任,能够保证产品的基本质量。测试遗漏是难免的,但是我们不能把线上问题简单的归结为对质量意识不强或者开发人员能力太差,测试应该有责任和能力去探查问题的根源并加以改进。我们不生产问题,但我们也不能让问题轻易地从自己测试的版本中遗留出去。出现问题并不可怕,可怕的是让问题重复出现而自己视若无睹。(个人也经历过比较重大的线上问题,复盘后给出改进项即可,很少会有团队因为线上问题就开掉测试人员的。但是这份责任,不能丢,你有义务去加以改进)
04 努力精进
很多人觉得测试不重要,门槛低。这种认知是我们自己造成的,早期的测试人员确实是这样的。但是,经过一批批测试人员的努力,不断地研究测试底层逻辑,提升测试能力。他们没有躺平在测试“仅仅是点一下、看一下、验一下”的认知中,而是通过提升自己的能力,通过单测覆盖、静态分析、接口测试、各类自动化手段,乃至于安全测试、埋点、监控、生产流量导入等等各种手段和方案,来提升质量,让产品的质量更加可靠,让测试的价值得以更好地发挥,每年的各类大会,就是很好的证明,测试人,不平躺。
05 小结
每一次的迭代交付,对测试人员而言就是一次展示自己的机会,做为测试人员,我们应该做到:培养一个完善的测试思维、编写一份简洁的报告;拥有承担一点责任的勇气,不断努力精进自己的测试能力。
附1:
重温下测试的底层逻辑吧:
-
贯穿整个研发周期,形成闭环,并持续改进测试流程
-
基于风险的测试策略是必不可少的
-
以终为始、系统地分析测试需求,在资源和测试目标之间寻求平衡
-
测试设计是艺术,更要创新、融合
-
在分析和设计的基础上,尽可能地实现自动化测试
-
讲好测试故事,和各方一致、协同工作
附2:
关于不同时期团队对于测试的要求,有一位答主的内容很详细,直接截图过来。
话题地址:https://testerhome.com/topics/32404