软件测试完后,还有BUG,是测试人员的问题吗?


达芬奇密码提问于 2018-06-20 14:24
2 个回答
  • 金和OA办公系统2018-10-17 17:44

    个人认为,这个问题不一定,这个要具体问题具体分析:

    首先,产品发布了出现bug,就是测试的问题了;

    其次,产品没有发布,存在bug:

            1、bug测试出来,开发没有修改好,或者引起了新的bug,这就是开发的问题;

            2、bug没测试出来,那就是测试的问题;

    以上都是个人观点。

  • 推荐我厂李丹同学的一篇文章,讲述了测试是如何推动开发质量改进的,希望对题主有帮助。原文如下:

    引言

    曾经, 我以为
    作为一名测试工程师, 提交bug就是我的本职工作。 bug提的多,说明我牛。
    直到有一天,我跟了一个烂项目(别慌, 是前任公司 ),逾期未交付, 做砸了~ 虽然我们测试团队报了上千个bug,可依然阻止不了项目的失败。
    我的总监(负责开发和测试团队)在绩效考核时,评价我的工作:“bug报的多,并不能代表什么,只能说明开发质量烂”,“项目失败了,虽然不是你的原因,但按照个人贡献,我只能给你打个Meet(合格)。”
    站在大boss的角度,是希望这个产品是成功的,高质量的。而线下bug多,都只是内耗。
    那,我, 一名测试工程师,我能推动开发质量的改进吗?
    有幸,在项目中,基于PDCA质量管理理念, 做了一次实践。



    1. 计划Plan

    1.1 分析现状

    项目负责人:
    为什么测试员都已经报了这么多bug,还是会有很多线上问题?
    整天在救火, 还怎么好好的做新需求啊!
    究竟是开发代码质量差,还是测试员覆盖不全啊?

    开发:
    我需求都没开发完,你们就催着提测,催着上线。
    哪有时间保证质量啊? 加班997, 都没时间和老婆生孩子了, 还要被责怪,我委屈啊委屈。

    测试:
    这bug都好low哦! block我测试了。
    这个bug 怎么还没改好啊?都打回2次了。
    啊? 怎么最后一轮还有bug啊!不开心。
    可是,还是得硬着头皮上线。
    宝宝心里虚啊!

    项目负责人:
    是时候整顿下了。

    1.2 分析原因
    既然是由bug引起的一场战乱,那咱就从bug着手。 于是,有了一周一次的bug回溯。

    分析哪些bug?

    • 线上的bug
    • 线下Critical 和 Major 的bug
    • 罗列出可以通过开发自测解决的bug


    分析什么?由谁分析? 怎样分析?

    • 每周挑选5个左右。
    • 分析 root cause, 以及落地改进方案。
    • 线下的bug改进方案由开发分析,线上的由开发和测试共同给出。
    • 每周周会,在测试发言环节,和所有人分享,其他所有人会进行补充并优化落地改进方案。


    bug回溯示例:



    1.3 制定计划
    落地改进包括两点:技术改进和流程改进。流程改进包含以下内容:

    • 简单粗暴的bug请开发加强自测。
    • 开发加强 code review
    • 测试加强业务异常以及系统异常测试
    • 其他流程上的改进。


    其他流程上的改进包含以下内容:

    • 对需求进行细化
    • 对接口进行详细定义和异常处理
    • hotfix 流程改进
    • 提测前客户端与服务器进行联调
    • 测试阶段进行bugbash
    • 整理并维护上线checklist


    2. 执行Do
    问题都已经暴露出来, 改进方案也有了。那么如何确保证这些改进真正地落实了。
    纵观整个改进方案,最难落实的应该就是开发自测和代码评审.
    开发先哭了,我们加班加点,周末无休, 需求都赶不完。还让我们自测,让我们代码评审。 我们也知道好处多多,but 时间啊, 时间啊~~
    头儿发话了: 需求是一定要赶的(竞品太多),但是质量也得抓。
    他捋了捋性感的胡须:“这样吧!下期需求,你们把自测和评审的时间都评估进去。随着你们对项目的逐渐深入, 对需求的评估能力应该会更加准确的。 到时候自测没做,可不能以时间为借口了哦!”
    会哭的孩子有奶吃, 时间终归是有了。
    那么怎么来监控开发自测和代码评审的过程呢? 毕竟这2个流程都是贯彻始终、持之以恒的事情!

    2.1 开发自测的监控
    我可能不用太关注开发冒烟通过率和完成度。流于形式的冒烟测试意义都不太大。
    我主要跟踪的是bug。每个版本统计易自测的bug数(所谓易自测,说的狠一点,就是低端bug,哦,请原谅我是一个刀子嘴豆腐心的人)
    说实在的,开发小哥们都是三观正、有理想的。谁愿意让人家指指点点bug多代码烂呢?
    之前真的是流程的问题, 真的是流程的,流程的问题~

    2.2 代码评审的监控
    gitlab自带code review 功能。
    跟踪者可以通过Activity 模块下的Comments 查看到所有评论。



    可以每周统计一次数据, 包括评论条数、内容、修复情况。
    示例:


    现阶段统计还属于人肉操作, 同时也正在研究专业的代码评审的工具Gerrit,应该会让整个代码评审的工作更加规范一些, 也便于统计。

    3. 检查Check

    检查是对执行后效果的评估,是伴随着实施过程自始至终的,不断收集数据的过程。


    版本时长: 计算开发开始--测试结束的时间。
    总开发人日: 所有的开发人员在这个版本中投入的人日总和。
    关注的指标: 总bug数除以总开发人日。
    实践2个半月后,统计了近7个版本的指标, 大家可以看到,最后2个版本,指标降下来。
    开发负责人: 质量好了,不用总是背锅了。
    测试: 郁闷,找不到bug了(其实有找到几个old bug)
    项目负责人: 测试找不到bug, 我也还是担心啊!
    我:测试期间找不到bug,同样的测试资源,只会比以前更心细。 测试深度更深。 对测试环节,请放心~~~

    4. 实践总结 Action
    以上流程核心: 以bug回溯的方式来推动开发自测、代码评审以提高提测质量,进而提高产品质量。并且,不断收集晾晒数据。
    开发鼓励坚持以这样的方式做质量改进原因如下:

    • 质量是真的在变好。提测后,发现的总bug数少了很多。
    • 开发把测试阶段修改bug的时间解放出来,可以做其他更有价值的事情。
    • 上线前所有人比以前更有底气了。
    • 整个团队规范性、自信心、士气、更好了。

    经过这次实践,我对钱老师所言是认同的 嫌测试周期太长,试试开发自测吧!
    因为整个产品开发阶段, 越早消灭bug,成本越低。 这就是为什么开展用例评审、开发自测的必要性!

    附1: 图中的改进体系是PCDA的落地版。 经实践,现阶段对于网易**项目是行之有效的。



    原文:PDCA 质量环之实践-----测试推动开发质量的改进