测试组会议
本周议题：设计实现与需求不一致该怎么处理
本周议题：设计实现与需求不一致该怎么处理
【前言】
A 提出： 规格和实际设计实现不一致，应该怎么办？特别是多次沟通无结果的情况下。规格不明确，问了也没答案，也没实时修改。
一、 现象描述
系统的设计实现与需求不一致，主要现象有：
1、规格不明确，开发就按照自己的理解去做了。
2、规格中有明确要求，实际实现的时候有难度、开发私下简化或改变。
3、开发口头和产品经理沟通之后，做了和规格不一样的设计，产品经理没对规格做出
修改、也没及时通知相关人员。
4、开发的概要设计文档对需求的覆盖不完全；
5、开发没有设计方案、直接编码。
6、开发的设计方案缺少全盘考虑、或者跟不上节奏：有的时候问开发某个模块，回答这个模块还没有考虑过。
7、开发有的设计方案不对测试公布。
8、以前有一些流程，测试与开发交互规范、测试与产品经理交互规范等等，但是没有执行。
二、 是否要解决
1. 产品质量的定义
产品质量的定义：产品与明确的和隐含的定义的需求相一致的程度。
从这个定义可以看出，实现与需求不一致显然是产品质量问题。
2. 给测试工作中带来困扰和不便
1、花费很多时间反复与开发、产品经理沟通；
2、会遇到沟通多次无结果的情况；
从上面的分析可以看出，设计实现与需求不一致的问题急需解决；
三、 原因分析：为什么问题没有消灭在萌芽状态
“低声传话游戏”，你传给我、我传给他，信息在流传中难免失真；而我们的项目研发工作比传话游戏要复杂得多，不仅有上传下达、还有功能的设计与实现，所以，难免会出错。
举一个生活中的小例子来进行原因分析：
通过上图可以发现现象：
1、 开发对需求理解不到位；
2、 开发实现有困难，但是没有和产品经理沟通、私下变更功能；
3、 开发与产品经理口头沟通，但是没有写到需求说明里、没有通知测试；
4、 需求本身模棱两可；
Bug 越早发现越好，修改成本越低。但是为什么需求与开发设计不一致的问题，我们没有消灭在萌芽状态？而是到了测试执行的阶段才发现？
四、 测试工作如何改进
前提条件：测试尽早介入项目：
1、 产品开始进入研发的时候，系统组进行需求分析的时候，测试就应该有人必须
加入。
2、 做规格分解的时候，开发主导、测试要参与规格分解的工作；
3、 开发的系统设计方案，应该要有测试参与思考测试策略、测试方案；
4、 开发的概要设计文档：测试参与开发的讨论、评审；
按阶段来改进工作：
1、 将产品设计与需求不一致的问题消灭在萌芽状态，设计测试方案阶段：
1.1 学习并分析产品需求规格书，发现不明确的地方当面请教产品经理，确保
正确理解产品的需求，沟通过程要有记录；
如果每个人都单独去找产品经理请教问题，会增加产品经理的工作量。建
议大家可以先把需求都过一遍之后、再找个时间订个会议室统一请教产品
经理；
1.2 熟悉开发的概要设计文档，不明确的地方请教对应模块的开发负责人，确
定具体参数。沟通和确认过程需要有记录。
1.3 发现开发的产品概要设计文档与需求规格不一致的地方，（包括功能参数和
功能覆盖），及时与开发、产品经理沟通；
1.4 多次沟通没有结果的问题，向项目测试负责人、项目经理、总监反馈。
1.5 保证清晰知道产品需求规格并了解产品设计方案。
2、 测试执行阶段：
发现产品实现与需求不一致，在JIRA 上提问题单，注明“实现与需求不一致”，并且注明“不一致的原因”，问题出在哪个环节。
不一致的原因有：需求模棱两可、变更未写到需求说明中、变更未及时通知大家、开发理解不到位、开发私自变更需求等等，测试要进行记录、每个项目总结时进行统计，先收集数据，后积极、主动推动产品经理和开发找改进措施。
五、 可能涉及的其他对象和输入输出建议
上图是测试V 模型，根据上图与公司的研发流程，可以看出从需求到系统测试的一些中间环节、可能涉及的人员；
同时可以看出：测试在规格变更管理流程中是一起参与的角色，还有其他成员共同参与。
1. 产品经理
1、 清晰提出产品需求的功能和特性要求，经过评审后，发送给项目相关人员；
2、 正式发布之后需求的管控要收到控制，尽量少的发布版本，
3、 如果产品需求规格书发生了变更，请提供变更清单并在规格书中标示，变更清单中
需要包括变更原因，变更后及时通知项目相关人员；
2. 项目经理
1、 把控和监督项目开发流程；
3. 软件、硬件开发工程师
1、 分析需求，思考是否能实现以及实现方式，与产品经理及时沟通；
2、 开发设计方案应该确保与需求一致，最好是得到产品经理的反馈意见，任务闭环；
六、 确定改进目标，营造改进氛围
前提条件：测试尽早介入项目：
1、 产品开始进入研发的时候，系统组进行需求分析的时候，测试就应该有人必须
加入。
2、 做规格分解的时候，开发主导、测试要参与规格分解的工作；
3、 开发的系统设计方案，应该要有测试参与思考测试策略、测试方案；
4、 开发的概要设计文档：测试参与开发的讨论、评审；
按阶段来改进工作：
1、 将产品设计与需求不一致的问题消灭在萌芽状态，设计测试方案阶段：
1.1 学习并分析产品需求规格书，发现不明确的地方当面请教产品经理，确保
正确理解产品的需求，沟通过程要有记录；
如果每个人都单独去找产品经理请教问题，会增加产品经理的工作量。建
议大家可以先把需求都过一遍之后、再找个时间订个会议室统一请教产品
经理；
1.2 熟悉开发的概要设计文档，不明确的地方请教对应模块的开发负责人，确
定具体参数。沟通和确认过程需要有记录。
1.3 发现开发的产品概要设计文档与需求规格不一致的地方，（包括功能参数和
功能覆盖），及时与开发、产品经理沟通；
1.4 多次沟通没有结果的问题，向项目测试负责人、项目经理、总监反馈。
1.5 保证清晰知道产品需求规格并了解产品设计方案。
2、 测试执行阶段：
发现产品实现与需求不一致，在JIRA 上提问题单，注明“实现与需求不一致”，并且注明“不一致的原因”，问题出在哪个环节。
不一致的原因有：需求模棱两可、变更未写到需求说明中、变更未及时通知大家、开发理解不到位、开发私自变更需求等等，测试要进行记录、每个项目总结时进行统计，先收集数据，后积极、主动推动产品经理和开发找改进措施。
七、 确定后续事宜跟进责任人
测试组会议
本周议题：设计实现与需求不一致该怎么处理
本周议题：设计实现与需求不一致该怎么处理
【前言】
A 提出： 规格和实际设计实现不一致，应该怎么办？特别是多次沟通无结果的情况下。规格不明确，问了也没答案，也没实时修改。
一、 现象描述
系统的设计实现与需求不一致，主要现象有：
1、规格不明确，开发就按照自己的理解去做了。
2、规格中有明确要求，实际实现的时候有难度、开发私下简化或改变。
3、开发口头和产品经理沟通之后，做了和规格不一样的设计，产品经理没对规格做出
修改、也没及时通知相关人员。
4、开发的概要设计文档对需求的覆盖不完全；
5、开发没有设计方案、直接编码。
6、开发的设计方案缺少全盘考虑、或者跟不上节奏：有的时候问开发某个模块，回答这个模块还没有考虑过。
7、开发有的设计方案不对测试公布。
8、以前有一些流程，测试与开发交互规范、测试与产品经理交互规范等等，但是没有执行。
二、 是否要解决
1. 产品质量的定义
产品质量的定义：产品与明确的和隐含的定义的需求相一致的程度。
从这个定义可以看出，实现与需求不一致显然是产品质量问题。
2. 给测试工作中带来困扰和不便
1、花费很多时间反复与开发、产品经理沟通；
2、会遇到沟通多次无结果的情况；
从上面的分析可以看出，设计实现与需求不一致的问题急需解决；
三、 原因分析：为什么问题没有消灭在萌芽状态
“低声传话游戏”，你传给我、我传给他，信息在流传中难免失真；而我们的项目研发工作比传话游戏要复杂得多，不仅有上传下达、还有功能的设计与实现，所以，难免会出错。
举一个生活中的小例子来进行原因分析：
通过上图可以发现现象：
1、 开发对需求理解不到位；
2、 开发实现有困难，但是没有和产品经理沟通、私下变更功能；
3、 开发与产品经理口头沟通，但是没有写到需求说明里、没有通知测试；
4、 需求本身模棱两可；
Bug 越早发现越好，修改成本越低。但是为什么需求与开发设计不一致的问题，我们没有消灭在萌芽状态？而是到了测试执行的阶段才发现？
四、 测试工作如何改进
前提条件：测试尽早介入项目：
1、 产品开始进入研发的时候，系统组进行需求分析的时候，测试就应该有人必须
加入。
2、 做规格分解的时候，开发主导、测试要参与规格分解的工作；
3、 开发的系统设计方案，应该要有测试参与思考测试策略、测试方案；
4、 开发的概要设计文档：测试参与开发的讨论、评审；
按阶段来改进工作：
1、 将产品设计与需求不一致的问题消灭在萌芽状态，设计测试方案阶段：
1.1 学习并分析产品需求规格书，发现不明确的地方当面请教产品经理，确保
正确理解产品的需求，沟通过程要有记录；
如果每个人都单独去找产品经理请教问题，会增加产品经理的工作量。建
议大家可以先把需求都过一遍之后、再找个时间订个会议室统一请教产品
经理；
1.2 熟悉开发的概要设计文档，不明确的地方请教对应模块的开发负责人，确
定具体参数。沟通和确认过程需要有记录。
1.3 发现开发的产品概要设计文档与需求规格不一致的地方，（包括功能参数和
功能覆盖），及时与开发、产品经理沟通；
1.4 多次沟通没有结果的问题，向项目测试负责人、项目经理、总监反馈。
1.5 保证清晰知道产品需求规格并了解产品设计方案。
2、 测试执行阶段：
发现产品实现与需求不一致，在JIRA 上提问题单，注明“实现与需求不一致”，并且注明“不一致的原因”，问题出在哪个环节。
不一致的原因有：需求模棱两可、变更未写到需求说明中、变更未及时通知大家、开发理解不到位、开发私自变更需求等等，测试要进行记录、每个项目总结时进行统计，先收集数据，后积极、主动推动产品经理和开发找改进措施。
五、 可能涉及的其他对象和输入输出建议
上图是测试V 模型，根据上图与公司的研发流程，可以看出从需求到系统测试的一些中间环节、可能涉及的人员；
同时可以看出：测试在规格变更管理流程中是一起参与的角色，还有其他成员共同参与。
1. 产品经理
1、 清晰提出产品需求的功能和特性要求，经过评审后，发送给项目相关人员；
2、 正式发布之后需求的管控要收到控制，尽量少的发布版本，
3、 如果产品需求规格书发生了变更，请提供变更清单并在规格书中标示，变更清单中
需要包括变更原因，变更后及时通知项目相关人员；
2. 项目经理
1、 把控和监督项目开发流程；
3. 软件、硬件开发工程师
1、 分析需求，思考是否能实现以及实现方式，与产品经理及时沟通；
2、 开发设计方案应该确保与需求一致，最好是得到产品经理的反馈意见，任务闭环；
六、 确定改进目标，营造改进氛围
前提条件：测试尽早介入项目：
1、 产品开始进入研发的时候，系统组进行需求分析的时候，测试就应该有人必须
加入。
2、 做规格分解的时候，开发主导、测试要参与规格分解的工作；
3、 开发的系统设计方案，应该要有测试参与思考测试策略、测试方案；
4、 开发的概要设计文档：测试参与开发的讨论、评审；
按阶段来改进工作：
1、 将产品设计与需求不一致的问题消灭在萌芽状态，设计测试方案阶段：
1.1 学习并分析产品需求规格书，发现不明确的地方当面请教产品经理，确保
正确理解产品的需求，沟通过程要有记录；
如果每个人都单独去找产品经理请教问题，会增加产品经理的工作量。建
议大家可以先把需求都过一遍之后、再找个时间订个会议室统一请教产品
经理；
1.2 熟悉开发的概要设计文档，不明确的地方请教对应模块的开发负责人，确
定具体参数。沟通和确认过程需要有记录。
1.3 发现开发的产品概要设计文档与需求规格不一致的地方，（包括功能参数和
功能覆盖），及时与开发、产品经理沟通；
1.4 多次沟通没有结果的问题，向项目测试负责人、项目经理、总监反馈。
1.5 保证清晰知道产品需求规格并了解产品设计方案。
2、 测试执行阶段：
发现产品实现与需求不一致，在JIRA 上提问题单，注明“实现与需求不一致”，并且注明“不一致的原因”，问题出在哪个环节。
不一致的原因有：需求模棱两可、变更未写到需求说明中、变更未及时通知大家、开发理解不到位、开发私自变更需求等等，测试要进行记录、每个项目总结时进行统计，先收集数据，后积极、主动推动产品经理和开发找改进措施。
七、 确定后续事宜跟进责任人