首先, 询问开发是否已经查看 bug 管理系统的 bug 描述和复现步骤.
如果, 开发没有查看 bug 描述, 告诉开发在 bug 系统中已经详细说明 bug 的复现步骤. 如果再有不明确的地方, 可以随时沟通.
如果, 开发已经查看 bug 描述, 还是有不清楚的地方, 那么需要针对有疑问的地方进行详细解释, 或者当面沟通.
最后, 需要反思自己提交的 bug 描述和 bug 复现步骤是否清晰明了. 提交 bug 的时候, 做到描述详细, 清晰明了. 如果是 UI 方面的 bug, 可以附上截图. 自己附上造成 bug 原因更好, 有助于开发定位 bug.
当开发自测不充分, 产品有严重 bug 阻碍测试
在提测系统中, 将本次提测打回, 注明理由 "冒烟测试未通过, 出现严重 bug, 阻碍了测试进行".
找开发沟通, 告诉开发冒烟测试未通过. 详细告知严重 bug 复现步骤和发生原因.
并且告知开发, 该 bug 严重影响到了测试工作开展, 希望开发修改 bug 充分自测之后, 再提测.
当开发实现的功能不符合产品需求
首先自己对产品需求进行客观分析, 如果产品需求是合理并且经过事先评审, 那么提 bug 给开发, 并且告知开发原因.
如果开发对产品需求有异议, 并且执意按照自己逻辑的开发, 那么可以拉上产品一起, 进行三方沟通, 达成最终方案.
当开发偷偷改代码, 直接上线出现了 bug, 求助你时
首先, 提醒开发进行版本回滚, 尽量避免线上影响.
然后, 和开发一起找 bug, 并且分析 bug 原因.
最后, 回顾整个事件, 告诉开发直接上线的风险所在. 并且推动上线流程体系完善, 只有测试完成并且无修改之后才能上线.
工作场景题
来源: http://www.bubuko.com/infodetail-3489119.html