四个小步骤,教你怎么做事故分析

2018-02-07   出处: LuckyFrame测试平台  作/译者: 文小刀  

前文说到“WHY-为什么要做事故分析”,那这篇,咱们来聊聊“HOW-该怎么做呢”。

可能也有很多同道QA,想过要做此类工作,但是无从下手。那么,我会就我自己两年来的经历,跟大家分享一下几个关键的点。


阅读已有材料,提取重要因子

什么叫做”已有材料“?

  • 开项目例会的时候,团队成员口头汇报的材料;

  • 运维监控系统发出的事故警报短信;

  • 项目组员处理事故的来往邮件;

  • 外部人员的投诉邮件;

  • 项目的需求文件,系统的设计文件;

  • …………

在小刀所在的公司,以上材料里面最先接触到的,是“事故警报短信”,一般发生事故的时候会提示是:XXXX时间点,XX系统的XX业务,发生了XXXX事件,现已通知某某某处理……

事故处理结束后会提示”XXXX时间点,XX系统XX业务上发生的XXXX时间,已经由某某某理完毕,恢复正常“。

那么在这组短信里面,我们就可以获取到发生事故的“系统和业务”“处理人”和“事故概述”这三大要素。

然后再结合其他几项:项目例会的交流、事故处理的来往邮件、项目的文件资料,可以稍微的对发生事故的业务内容以及事件经过有一个大概的概念。

这个概念的清晰程度,取决于QA融入项目的深度。

融入得越深,对事故的第一印象也就会越发清晰;

如果比较游离于项目工作之外,那么这个概念就会相对而言比较淡薄。

采访会谈,听听各方的描述

所谓的采访会谈,指的是需要跟各环节人员的进行面对面的沟通了解。

  • 为什么是“各环节“而不是”就近原则“

什么叫做“就近”:QA工作日常密切联系的项目组的开发+测试+运维,而业务端的客服、运营等人员,是相对而言较“远”的。

那么在做采访会谈的时候,如果只跟“近处”的技术人员了解,那么我们很有可能也就只能了解到“系统上出了什么问题”,而不是“整个事件出了什么问题”。

  • 所谓的“面对面”,指的是尽量当面谈。

带上笔、笔记本、笔记本电脑,而不是通过QQ/RTX/微信的谈。

这样才能够保证面谈的双方人员是专注在这件事,而不至于被其他工作打断节奏。

而且,面对面的对话,更能让对方回忆起“细节”。

记录有用信息

在面谈的过程中,尽量按照”先大后小“的顺序去记录事件。

也就是说,先记下事件的大要素”XX时间点,发生了XXXX事件,然后XXX去处理“。

然后再针对大要素去展开小要素。

所需要考虑的大小要素,我们可以参考学生时代“叙述文的六要素”来规划

(以上图中的列出点,仅仅是小刀所在部门经常涉及的因素,并不可能全面覆盖所有场景)

其中做了标记的点需要特别留意。

绿色对号:这些是重点,在采访的过程中,一定要反复落实以保证其可靠性和真实性。

必要的时候,可以针对某一个细节反复采访不同岗位方向的相关人员,多方求证,才能力保它的真实性。

橙色叹号:如果对此项内容没有要求,就一定不要去提及;如果有要求,在拟文的时候,一定要跟对应部门(比如人力资源部、行政管理部、财务部、法律事务部等)的人员落实其具体的数据、范围等。

因为这是容易引发劳务纠纷的点,要慎重再慎重。


整理材料,输出定稿文档

在第三步结束之后,我们收集到了很多有用的材料,但是这些材料还只是记在笔记本或者电脑上的零散片段,并没有形成一个完成的报告,而小刀所在的公司,是要求每个季度做分析会的,那么就需要将以上材料整理成正式的文档格式。

Word文件

用以向部门领导及公司管理层汇报事故过程。

那么在写文件的过程中,需要注意汇报的对象层次不同,关注的点不同:

部门领导可能会关注事故的技术因素,处理的过程,花了多少时间,有没有反复处理还有问题的;

而公司管理层则可能更关注事件的影响程度,如何避免以后再次出现的计划。

PPT稿件

用以向部门做分析会展示课件——毕竟,开会的时候,不可能把一份好多页的Word文字版内容投影给大家看吧。

那么这个,就很考验QA的课件制作水平啦。


做事故分析的过程,大概就是包括这几步啦,各位小伙伴你们有没有类似的经验,可以给我留言,互相学习哦~~~~

下一章,小刀将跟大家继续聊聊,做事故分析的时候,QA应该具备哪些技能或者说素质要求?如果你有什么想说的,也欢迎留言哦~~~~




欢迎给测试窝投稿或参与内容翻译工作,请邮件至editors@testwo.com。也欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,并与我们的编辑和其他窝友交流。
180°|1808 人阅读|0 条评论

登录 后发表评论
最新文章