缺陷定级

去年我陪一家做 SaaS 的团队做了一次缺陷管理复盘，把他们过去 12 个月提交的 3847 条缺陷记录全部拉了出来。结果有点刺眼：其中标为 P0 和 P1 的缺陷占了 41%，但…

去年第三季度，我参与了一家工业软件公司的版本延期复盘。他们的测试团队只有 12 个人，一个版本周期内提了 1,847 条缺陷，开发修复了 1,600 多条，看起来产能不缺。但版本还…

“严重程度”最容易被做错的地方，不是缺少 P0、P1 这样的等级，而是每个人都能给缺陷定级，却没人能解释为什么这样定、谁有权调整、什么情况下必须升级。结果往往是：测试人员把“页面错…

同一个缺陷，研发可能标成“严重”，产品经理却认为可以等下个版本；真正让团队失控的，往往不是这次判断谁对谁错，而是“严重程度”被当成了紧急程度、修复优先级，甚至个人主观感受的代名词。…

缺陷单越多，产品质量就越差吗？我在项目复盘中反复看到相反的情况：有的团队每周关闭数百条缺陷，版本仍然频繁回滚；有的团队缺陷总量不低，却能按风险完成分流，发布后问题反而更少。差别通常…

同一个“登录失败”缺陷，可能只是测试环境配置错误，也可能让全体客户无法进入系统；如果团队只凭提交者的紧急程度定级，前者容易被抬成最高级，后者也可能因为描述平淡而被排到队尾。Bug …