一、风险识别清单
1、需求
- 产品的业务需求、用户需求、功能需求和系统需求是否完整、清晰?
- 开发人员在产品开发设计之前是否充分了解需求?
2、设计
(1) 是否使用了“新技术”?
(2)系统中是否会存在一些设计“瓶颈”?如果存在,是否有应对措施?
(3)产品是否设计得过于复杂,难以理解?
(4)开发人员是否能够讲清楚产品设计?
(5)开发人员对异常、非功能方面的内容是否考虑得足够全面?
(6)开发人员在设计中是否存在一些比较担心的地方?
(7)开发人员是否会考虑和设计一些可测试性或者易于定位的功能?
(8)对一个需要多人(或多组)才能配合完成的功能,是否有人会进行整体的设计、协调和把关?
(9)对有依赖或结束的内容,是否有充分考虑?
3、流程
(1)项目是否使用了新的流程、开发方法等?
(2)开发人员是否会进行自测?是如何进行自测的?测试的深度和发现问题的情况如何?
(3)开发人员如何进行代码修改,是如何保证修改的正确性的?
(4)开发人员是如何进行版本管理的?
4、变更
(1)新版本在旧功能方面做了哪些修改?修改后的主要影响是什么?
(2)在项目过程中,需求是否总是在变更?
5、组织和人
(1)哪些模块是由其他组织开发的?他们在哪里开发?开发流程、能力如何?
(2)产品的研发团队(包括需求、开发和测试)是否在于不同的地方?彼此分工如何?沟通是否顺畅?
(3)团队人员能力如何?经验如何(包括需求、开发和测试团队)?
(4)团队是否稳定(包括需求、开发和测试团队)?
(5)团队人手是否充足(包括需求、开发和测试团队)?
(6)团队环境是否具备(包括必备的工具、硬件设备)?
6、历史
(1)哪些特性在产品测试时就存在有很多bug?
(2)哪些特性存在较多的客户反馈问题?
(3)历史上上哪些情况曾经导致过阻塞测试活动的问题?
二、风险评估
风险评估的目的:确定风险优先级
1、风险优先级正交表
根据风险发生频率和风险影响程度,“高”“中”“低”相互交错来判断
2、需求类的风险
- 需求的质量不高,不足以支撑后续开发和测试
- 开发和测试未能正确理解需求
需求类的风险,对设计、开发、测试的影响较大,因此风险的影响程度和风险发生频率设置为“高”,重点关注
3、设计类风险
设计类的风险主要集中在设计的正确性和全面性上,这些风险一旦成了问题,就是产品缺陷。对于这些由风险引起的缺陷,评估一下:
(1)测试容易发现这些缺陷吗?
(2)开发修复这些缺陷的改动大吗?影响的功能模块多吗?
(3)测试容易验证这个缺陷吗?回归测试的工作量大吗?
(4)如果这个缺陷逃逸到了用户处,对用户的影响大吗?
一般来说,对于测试难于发现的缺陷,风险的影响程度更高;基础的、底层的、共用的设计,风险的影响程度更高;需要特殊测试工具或复杂测试环境才能验证的,风险的影响程度更高;在用户处发生概率高、会对用户的业务造成更严重影响的问题,风险的影响程度更高。
4、流程类的风险
从风险影响程度来说,会影响团队合作,或是涉及规范性方面的风险,风险影响程度更高,建议至少为中级
5、历史类的风险
历史上曾经发生过的问题,再次成为问题的风险依然很大。所以建议风险发生的概率应该总是高的
三、风险应对
1、回避风险:指主动避开损失发生的可能性。
2、转移风险:指通过某种安排,将自己面临的风险全部或部分转义给其他一方。
3、减轻风险:指采取预防措施,已降低损失发生的可能性和影响程度。
4、接受风险:指自己理性或非理性地主动承担风险。
四、常见风险及应对思路
1、需求类的风险
(1)问题:产品需求在业务场景上描述不够完整、清晰,不能有效指导开发人员和测试人员的工作。
解答:A、加强对业务场景的评审
B、加强开发、测试和需求工程师对业务场景的沟通、讨论,保证开发、测试和需求工程师对场景的验收条件的理解是一致的。
(2)问题:开发人员在进行产品设计之前并没有充分理解了产品需求,特别是在易用性和性能需求方面
解答:A、开展开发人员对需求工程师进行需求确认的活动,确保需求理解的一致性;
B、开发人员需要逐一根据需求编写验收测试用例,确保需求能够被正确实现,无遗漏;
C、开发人员针对易用性进行低保真、高保真设计,并和需求工程师进行评审确认;
D、在需求中需要明确产品的性能规格
E、测试人员尽早展开和产品性能相关的摸底测试。
2、设计类的风险
(1)问题:产品使用了新的技术平台
解答:A、将新平台与旧平台进行差异化分析,确定变化点
B、针对变化点进行专项测试
(2)问题:产品设计得过于复杂,难以理解
解答:A、和需求工程师进行沟通,确认设计没有超过需求要求的范围;
B、要求开发人员对设计进行讲解
C、增加这部分的测试投入
(3)产品中存在需要多人(或多组)才能配合完成的功能,且缺少这个功能的总体负责人
解答:A、建议开发增加一位总体责任人,负责确认接口、整体协调等;
B、建议开发人员对该功能设计自测用例,并在评审开发自测用例时进行确认;
C、将该功能作为接收测试用例,避免该功能造成测试阻塞;
3、流程类风险
问题:开发自测不充分
解答:A、和开发人员约定,在本轮版本转测试的时候,需要提供详细的自测报告;
B、评估开发人员自测用例的质量,必要时提供用例设计指导或直接提供测试用例;
C、搭建自动化测试环境,供开发人员自测使用
4、变更类的风险
问题:项目过程中,需求总是在增加
解答:A、和开发人员、需求工程师进行沟通,进行需求控制
B、裁剪部分低优先级的需求
5、组织和人
(1)问题:测试团队大部分人员没有测试设计的经验
解答:A、在进行测试设计之前,找 写的好的测试用例作为例子
B、增加测试设计的评审检查点,如测试分析、测试标题和测试内容分别进行评审;
C、必要时,测试架构师对测试工程师进行一对一的辅导
(2)问题:xxx测试工具不具备,需要购买
解答:A、定期跟踪工具购买进展;
B、寻找是否有替代工具。
6、历史类风险
(1)问题:xx特性在基线版本中就存在很多bug
解答:对基线版本该特性的缺陷进行分析,分析哪些测试手段容易发现该特性的问题,据此增加探索式测试
(2)基线版本中,开发人员修改引入缺陷导致缺陷趋势无法收敛,对测试进度和产品发布造成了影响,在继承性版本中可能存在相同的风险
解答:对基线版本中开发人员修改引入缺陷的问题进行根因分析,针对根因制定措施