lf知识星球banner

“有章可循,有据可查”——ISO9001:2015小课堂(1)

2018-03-13 17:14:00
文小刀
原创
4432

有很多人对于 ISO9001质量管理体系 并不看重,认为它“就是要我们写各种文档,现在工作节奏那么快,谁有空总写文档啊”。


文档这个东西吧,说起来确实很让人头疼——

自己看不到前人留下的任何文件记录的时候,就会痛恨“怎么没有文件给我看,鬼知道这个东西是干嘛的”。

但是,等到要自己抽出时间,按照格式要求去写文档的时候,又会抱怨“都这么忙的要死了,还写个什么,谁耐烦写谁自己写去”。


那么到底文档(或者说记录)有多重要呢?来看看今天发生的一件事以及我的看法。

今天上午,听到组里面一个妹子发火:

————我当初测试这个的时候,用需求范围外的用户做过测试,业务部门的人说没有必要测;后来也给业务部门的人提过,要给用户做限制使用,他们说没必要,不会开给范围外的用户。结果上线了,现在发生了事故,就是他们开出去了,现在来怪老子测试的时候没有考虑完全。


在这里,我们不去分析事件的详细过程,暂且当做妹子说的就是全部事实,那么试着想一下,下次碰到类似的风险问题,该怎么做:


确认需求范围

如果需求范围说是针对A类用户可用,B/C/D类用户不可用,那么需求说明书中就应该明确:对B/C/D类用户是什么样的设置?

在系统上设置完全不可见?

设置可见但是点击时会弹出警告窗?

甚至 可能是全部字段都可填到最后提交数据的时候才弹出警告窗?


做好设计方案

迭代启动会上分析需求的时候,设计人员(如果有的话)应该做好此“屏蔽措施”的设计要求。

哪个节点的操作会触发“屏蔽”响应?

触发的时候警告窗是否会影响原流程的无缝继续?


确认测试用例

测试人员在做测试用例输出时,应该把这个限制条件作为用例之一考虑进去,并且跟设计师&产品经理&需求方确认用例所描述的场景、警告窗格式等是否无误。


用正式形式反馈测试结果

在做执行测试的时候,如果测试结果符合需求所说的情况,那么直接记录输出测试结果即可;

如果不符合,应及时用书面形式(比如邮件)向开发组、项目经理、产品经理、需求方反馈出来。


从这个妹子的描述语句来看,很有可能在以下几个环节都没有做到位:

  • 需求说明书上没有提到B/C/D类用户的限制措施;

  • 在项目启动的时候没有考虑到相关的设计要求;

  • 开发在编写代码的时候也没有了解到有此限制条件,编码的结果开给了所有用户;

  • 测试在发现问题后,虽然是反馈了该问题,但可能只是在即时通信工具(比如QQ/RTX/微信)上跟需求方“说了一声”,并没有走正式途径;

  • 可能只有回复消息的那个QQ号成员知道此问题,而项目组的其他人并不知情。

  • 如果以上环节都是没有问题的,那就好好查一下生产环境上的代码或者系统的操作日志,是不是跟测试的代码或者测试环境配置一致?是否有人在测试通过后,又改了代码才部署上线?或者改了系统上的设置条件?如果是有人改了,为什么改?是否有足够的依据支持他做私自改动?


那么回到第一段话,在ISO9001:2015标准文件中,有对应的一个条款,就是为了避免这类现象发生:

4.  组织的背景

4.4  质量管理体系及其过程

4.4.2  在必要的范围和程度上,组织应:

a)保持成文信息以支持过程运行;

b)保留成文信息以确信其过程按策划进行。


说白了,就是 “留证据”

——你要我做什么?要我怎么做?什么时候做?做到什么样的程度?

——我做的过程是否符合你的要求?我做完以后的结果是否符合你的要求?产生的问题是否有相应的解释?

在现在快速发展的互联网行业,节奏快,涉及人员多,需求变更频繁,如果凡事都只靠“口头相传”,或者是“我相信你这个人”,那总会有出现“证据”遗漏的情况,那么为了避免此类情况,唯有“白纸黑字”“立字为证”是最好的办法了。



以上仅是QA的个人见解,大家还有没有其他想法呢?


文章原创申明
  • 本站文章以及相关内容除注明 转贴外,均为本站 原创翻译

  • 如果本站转载的文章涉嫌侵犯了您的权益,请在评论区留言或是邮件联系管理员及时删除 【admin@luckyframe.cn】

发表评论
评论通过审核后显示。
付费知识圈