质量保证组职责说明

1、质量保证组（简称：质保组）一、 目标协助研发对项目周期中产生的相关文档进行评审，展开内测工作，保证部门整体管理及产品质量品质的提升。二、 主要职责1、 作为研发与需求、UE、测试的统一接口人，起到沟通协作、承上启下的作用；2、 负责对需求部提交的需求规格说明书进行评审；3、 负责对UE部提交的高保真/低保真、通用规则进行评审；4、 负责对测试部提交的测试用例进行评审；5、 负责对测试部提交的Bug进行确认；6、 参与需求变更的评审工作，负责将变更内容及时、有效地反馈给研发，并负责跟踪需求变更在研发的对应情况；7、 负责在提交测试部测试前根据项目情况进行功能走查或功能测试。三、 职责流程图任务说

2、明：1、 各类文档的评审 目前暂定采用问题跟踪表的形式（后期考虑转移至Jira中，以实现问题的统一管理、确认及跟踪，具体的流程定义待定） 以所有问题全部确认关闭为原则。2、 需求变更控制 需求变更的发起：由需求自发产生，由UE在设计高/低保真时产生，由研发在设计或编码时产生，由测试在编写用例时产生 需求变更的反馈：a) 发起人直接与需求人员进行问题的沟通及确认；b) 若需求发生变更，需求人员发送变更通知的mail必须抄送给质保组；c) 质保组将需求变更的mail转发给相应的研发人员，若是由研发人员发起可省略该步；d) 质保组需要跟踪需求变更的对应情况。 需求变更的跟踪：考虑使用Jira进行管理

3、，具体的流程定义待定3、 外测Bug的处理流程 测试部提交Bug； Bug会自动先分配给质保组（各服务单元对应质保组成员名单在测试前会发送给测试经理，配置在bugzilla中，不需要手动进行该步骤。）； 质保组接收到分配给自己的Bug后，首先确认Bug的有效性；a) 判断为无效的、无法重现、需求变更的Bug需要跟Bug的提交者进行沟通确认，确认后，直接将Bug置为已解决，解决途径选择相应选项，并在备注中说明已经与何人进行了确认，确认结果及原因；b) 判断为重复的Bug，需要跟Bug的提交者进行沟通确认，确认后，直接将Bug置为已解决，解决途径选择已修复，在备注中说明已经与何人进行了确认，确认与

4、哪一个Bug重复； 判断为需要修改的Bug，质保组将Bug分配给技术经理，有必要时可以补充相应的备注说明，在标题处以“*”开头标识Bug的缺陷类型； 技术经理接收到分配给自己的Bug后，进行Bug修改的判定，a) 判定为需要修改，则根据Bug的优先级、严重度，综合评估目前研发人员已分配Bug的对应情况，将Bug进行二次分配给具体的研发人员；b) 判定为决定不改、稍后再改的Bug，直接将Bug置为已解决，解决途径选择相应选项，并在备注中说明原因； 研发人员对分配给自己的Bug进行调查对应a) 对应修正完毕，自测没有问题后，将Bug置为已解决，解决途径选择已修复，在备注中说明修改内容，若缺陷类型定

5、义有误需要修改；b) 调查后对Bug有疑义的，可以再与质保组沟通，根据实际情况判定解决途径。 测试人员会根据计划对已解决状态的Bug进行回归确认a) 确认没有问题，测试人员会将Bug直接置为已关闭；b) 确认存在问题，测试人员会将Bug重新打开，并在备注中说明返回的原因，研发人员接收到返回给自己的Bug后，重复执行步骤附：缺陷类型缺陷类型说明Bugzilla中如何对应的补充说明【需求】未明确定义需求中没有明确的定义，导致实施结果与测试用例不符此类Bug，置为需求变更，请跟踪需求进行补充或修改，需要在备注中补充说明【需求】描述不清需求中有相关定义，但是理解会产生歧义，导致实施结果与需求不符【功能

6、】正常系逻辑错误基本功能按照正常业务流程进行使用，出现错误此类Bug需要修改【功能】异常系逻辑错误进行异常系测试，发现的功能性错误【功能】功能点遗漏需求中有明确定义，但是没有实现【功能】关联模块错误在测试A模块时发现了关联模块B的问题此类Bug需要重新分配给关联模块的负责人进行修改【功能】JavaScript错误进行操作时，页面抛出JavaScript错误此类Bug需要修改【界面】格式校验错误【界面】提示信息错误【界面】界面不一致【界面】低/高保真错误高保真或低保真本身存在错误，即不符合需求或通用规则此类Bug，置为需求变更，请跟踪低/高保真进行了修改或补充，需要在备注中补充说明【界面】与低/

7、高保真不符实现的结果与低/高保真的设计不相符此类Bug需要修改【界面】框架、组件错误此类Bug需要重新分配给框架或组件的负责人进行修改【界面】浏览器错误相同的功能在A浏览器下可用，但B浏览器下不可用时使用。【建议】易用性错误建议级的Bug不一定要当时进行修改，此类问题需要与组长讨论后再做决定，涉及到需求、UE的地方，由组长沟通后反馈给研发和测试人员。【建议】功能错误需求中定义的交互或功能存在微不足道的问题，不修改也不会对整体功能产生影响，只是建议进行修改【建议】功能点遗漏需求中没有定义，提出的问题微不足道，不修改也不会对整体功能产生影响，只是建议进行追加【标准】不符合通用规则需求中没有明确定义，但是通用规则中有定义，而实现的结果与之不符此类Bug需要修改【其他】接口问题【其他】环境问题【其他】DB问题【其他】性能问题【其他】其他所有类型均不能准确定义该Bug类型，需要在备注中补充说明，以便后续缺陷类型的补充4、 内测的形式根据项目的实际情况安排测试计划对比测试方式功能走查功能内测测试依据需求跟踪矩阵需求规格说明书侧重点大体基本功能是否实现功能操作是否抛出异常或错误基本业务流程能否走通需求中要求的业务规则实现完整且正确；进行异常系的测试；从需求、功能、界面等各方面进行测试，提出问题；耗时相对较短相