工程师应该具备产品化思维吗—软件测试进阶之路(13)

发表于:2018-10-22 16:16

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:何飞    来源:51Testing软件测试网原创

分享:
  问答(35) 收到现网问题,除了解决,还能做什么?
  【背景】
  现网问题,也就是产品发布后,用户或客户的问题反馈。大多数公司都是由测试人员对接,经过筛查或复现,再反馈给客服或交由开发人员修复。有些即将承担或者已经承担该项工作的同学就问我,遇到这种问题,真正能解决的人最终还是开发人员,那测试人员在整个过程中,除了协助解决和验证,还能做些什么呢?
  【你问】
  收到现网问题,除了解决,我还能做什么?
  【我答】
  遇到问题,第一时间去解决,的确没错,这是正确的响应行为。但我认为,既然问题已经发生了,解决问题只是一个理所应当的动作,但仅仅解决完,还不到松口气的时候。真正重要的事情其实是在问题被解决之后才刚刚开始,而这些恰恰是最容易被忽略的。
  首先,我们要对现网问题进行分类统计,后续才好根据不同类别的问题再进行后续深入动作。我个人理解,主要就两类问题:
  一、缺陷
  也就是 Bug,对这类问题需要做3W分析,这个分析其实在接到现网问题时就会去分析,但在事后还是需要再分析一次,因为在处理问题时的分析也许相对个体化或特例化,在事后其实就可以集中一些同类别的现网 Bug 做更垂直深入和拓展性的分析。
  What's the problem? 问题是什么?
  对问题做一个清晰且专业的描述,因为,往往现网反馈的问题,只是表象上的描述或者只是非专业的破碎化的叙述,我们需要对它们做一个"转译",便于后面会说到的再利用。
  What's the root cause? 根本原因是什么?
  找出会产生此类问题的根本原因,我所遇到过的有这样几类:
  1、测试用例没有覆盖到;
  2、测试策略没有考虑到;
  3、测试执行的遗漏;
  4、系统没有做相应的操作保护,用户操作导致的异常数据;
  What's the solution? 解决方案是什么?
  针对 1 和 2,要从测试用例的设计方法和测试计划环节着手去提高和改进;
  针对 3,要从测试过程的监控和测试产物质量的验收环节着手去提高和改进;
  针对 4,要从自身系统的易用性和健壮性考虑,去提高和改进;
  二、操作问题
  从这类问题中,我们一般会汇总产出两样东西:
  1、常见问题解答 FAQ;
  这个常见问题解答除了可用于产品帮助文档的补充,或客服的问题参考文件之外,还有一个比较重要的功能,就是我们通过整理这个常见问题解答的过程,可以分析出一些我们没有想到过的用户行为习惯,往往可以帮助我们找到一些潜在的系统问题。
  2、产品交互设计的改进;
  这个产物可以帮助我们的产品交互设计师持续提高产品的用户体验满意度。
  在现网问题的处理过程中,还有一个重要的可持续更新的产物,那就是"现网问题信息确认清单",这个 Checklist(检查清单) 主要包含某一类多发型问题,在用户反馈到客服处时,客服需要跟用户沟通收集哪些必要信息,一方面对问题可以做一次初步筛查,另一方面也为后续技术部门查原因提供了更为完整的信息。
  只有做完上述这些事情,我们才能松一口气。这也是我始终坚持的一个观点,就是现网问题的处理过程一定要和产品研发过程(至少是产品质量检测环节)形成一个闭环,即从现网问题的处理流程中获取到的产物,一定要作用于产品研发或质量检测流程,改进也好,补充也好,杜绝也好,都不能落在空处,否则现网问题的处理就仅仅只是停留在解决问题的表层,而无法真正做到避免同类问题再次发生。
  我们可以允许自己第一次犯错,但一定不能允许自己再次犯同一个错。

相关阅读:
版权声明:51Testing软件测试网获电子工业出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任。
33/3<123
100家互联网大公司java笔试题汇总,填问卷领取~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号