加V:19841731,领 MTSC 大会历届 PPT

【原创】浅谈测试前移

上一篇 / 下一篇  2019-03-18 12:18:44 / 个人分类:测试基础


目前的现状。

bug 太多,懒得写 bug 单,很多需求合理性的验证都放到测试阶段,比如文案的测试,逻辑实现的健壮性也是留在了测试阶段,稍微一点异常就容易挂掉,然后就是各种改,提测次数频繁。

从我目前面试的经验看,不管是社招还是校招,有不少人选择测试的原因都是测试门槛低,不会的能很快学会,稍微好点的是因为够不上开发的标准,所以才选择做测试。

在这样的大环境下,导致很多测试人,自己都觉得测试的技术含量不高,开发更是觉得自己理解的测试没技术含量是正确的了,然后大家就进入了这个恶性循环的怪圈。

而且从测试这个 title 来看,也容易让人误解为所有需要验证的东西都是测试人员的职责,


为什么要前移?

如果不前移,测试人员就算忙死,对整个团队的质量保证的贡献也是有限的。

因为很多的测试验证工作都是一次性的,不可复用的,做自动化吧,不值当,不做自动化吧,很繁琐。

同时因为质量保证时间点后移,导致测试人员的时间开销特别大,能分配到做一下随机测试和深入逻辑验证上的时间非常少。

这样导致的问题就是,每次填坑的同时也在不停的埋坑,很多当前不会发生的问题,以及很长一段时间没人触发的问题,在之后的某个时间点,突然爆发,然后就需要重新花时间填坑,同时又会埋一个新坑,最后谁也不知道到底有多少坑,到底什么时候会把什么坑给暴露出来,这也是一个恶性循环。

如果测试前移了,很多基本的质量问题都可以在前期得到保障,就算提测时间晚,但是提测质量高,测试可以花更多的精力做更深入的测试,发现的 bug 肯定也都是质量比较高的了,同时这样的项目发布,埋坑的可能性就小,我们只需要关注本次修改内容及其影响范围即可,这才是良性循环。


如何前移?

我的答案是,测试即服务。

作为质量保证部门,我们的职责是保证产品的质量,但并不是说一定要我们去做具体保证质量的事情,所以换个角度,我们可以把我们保证质量的能力输出给真正能影响产品质量的人。

比如我们给产品人员提供服务。加强需求评审阶段的投入,把我们对于用户角度的思考,把我们对于需求合理性的思考,把我们对于产品质量预防的经验,在需求评审阶段就进行输出,把我们已知的问题在需求评审阶段都消灭掉。

比如我们给开发人员提供服务。给开发提供完备的编译环境支持,环境中可以包含必要的白盒检查、自测环境、冒烟测试用例,甚至是提测前的代码 review,把我们对于代码质量的基本要求和规范,都在代码编写阶段进行解决,从而把我们已知的编码中可能出现的问题尽可能的消灭在提测前。

产品和开发是和我们质量保证联系最紧密的两个角色,如果能把这两个角色的服务做好,基本可以保证提测质量了,也就能满足我们最低的测试前移的要求了。

当然,如果要达到这样的效果,更多的是对我们测试人员能力的更高要求,所以,为了可预见的美好未来,一起加油吧。

以上,如果认同我的观点请转发让更多人看到,或者点「好看」让我知道你的态度,如果有更多想法,欢迎留言和我讨论,期待。


TAG:

引用 删除 JINjin,   /   2019-05-15 16:14:36
5
 

评分:0

我来说两句

sylan215

sylan215

加V「19841731」,领 MTSC 大会历届 PPT。

日历

« 2021-10-19  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 69965
  • 日志数: 90
  • 图片数: 1
  • 建立时间: 2018-07-03
  • 更新时间: 2020-04-29

RSS订阅

Open Toolbar