百度软件测试工程师能力胜任力模型.docxVIP

百度软件测试工程师能力胜任力模型 邮件群发 百度测试工程师胜任力模型 ( 任职资格标准 ) - QAD QAT 胜任力模型说明 : 胜任力模型作为 QATC职称评定标准的细化与解读，帮助 QA更好的理解各职称 级别对于工程师的能力要求。 细则中对各级别工程师，在四个维度上的要求是 and 的关系 ; 每个级别的单维 度下有多条能力描述，这些描述也是 and 的关系 从胜任力角度看，这四个维度同样重要，理想情况下各级别工程师需要达到所在级别四个维度的所有要求 ; 但具体在职称评定过程中会根据工程师的技术特点和项目背景，在四个维度的要求上有所侧重 高一级别 ( 比如 :T5) 的职称要求，包含所有低于此级别 ( 比如 :T3/T4) 的职称要 求 文中所说的“能够”“胜任”等字眼，是强调工程师的能力 ; 而不是要求工程师一直做这些事情 ; 限于篇幅，本文也不对“能够”“胜任”等的衡量标准进行解读，最终解读权在 QATC QA: 问 : 该文档有什么用处 , 答 :QATC将使用该文档的标准，对 QA工程师进行职称考评 ; 工程师也可以根据本文档标准，定期与经理沟通自己在胜任能力方面的状态，并结合自身职业发展规划，制定个人能力提升的 KPI 计划。 问 : 为何没有 T10+的 QA标准 , 答 : 本文档只对 T3 至 T9 级别进行说明。 T1/T2 限于篇幅，不作说明 ;T10 以上标准整个技术部统一，所以就不列出了 问 : 为何胜任力对 QAD与 QAT之间不区分 , 答 : 职称级别越高，区分度越小。不管是 D 还是 T，主要是看其能力，以及对于项目贡献度。 各级别说明 T3 胜任复杂模块或简单子系统的测试工作。能够提出改进被测系统可测试性的需求，维护或新增自动化测试方案的设计、实现，或开发辅助测试工具，工作质量和效率都很高 ; 有较强的工作协调和推进能力 , 工作非常主动 ; 具有较强的缺陷分析能力和问题定位能力 . 产品或测试沟通阶段 , 能够理解要测试的功能或产品 ; 主动与 RD/PM询问 , 能够澄清产品或沟通中的模糊点 测试设计阶段，编写的清晰而且结构化的测试文档，被他人易于阅读 测试执行阶段，能够发现测试设计漏洞 , 并补齐测试用例 ; 对测试 fail 进行初步分析和定位，编写清晰的 bug 描述 结项阶段，能够编写清晰、有效的测试总结，并跟踪项目安全上线或发布 能够理解产品用户的主要使用情景，据此设计对应的测试用例 基于对用户和产品的理解，能够坚持质量标准，从而提高产品的用户体验 参与产品设计或 MRD评审时，主动思考产品功能的可测性和用户易用性，能够提出有效意见和需求 能够根据沟通或文档 , 参与制定测试计划，完成工作量评估，并得到 QA组内以及对应 RD/PM认同 T4 胜任简单子系统的测试设计和执行测试。能够具有较强的系统设计理解能力， 能发现简单子系统结构上的薄弱环节，进而制定测试策略。能够依据需求、设计文 档进行自动化测试方案的设计、实现，并取得较好效果 ; 在测试技术和工具等方面 有一定的视野，工作质量和效率都很高。能主动思考测试方法、自动化方案等存在 的缺陷，并设法改进。 产品或测试沟通阶段，能够向 RD提出合理的可测性需求，使得项目测试效率 或质量得到提高 测试设计阶段，能够设计或改进相关测试方案以及工具，从而能够发现更多的 bug，或提高测试覆盖率 ; 测试过程中，能够分析产品代码，指出简单代码 bug，或者利用代码 diff ，确定测试方法和用例 测试过程中或项目总结时，能够通过分析产品已发现的 bug，找出测试中质量风险较高模块或功能，给出测试的改进建议，弥补漏洞 根据使用反馈，能够分析出潜在的功能或质量缺陷，提出改进意见，从而推动产品质量的提高 基于对用户和产品的理解，能够提供各模块或功能的测试力度 / 产品质量标准的判断建议，协助主管在项目质量与效率之间作出权衡 能够对产品的易用性有较好的理解，并提出有效的建议能够分享竞争产品的知识，帮助改进项目设计和功能 对产品设计和实现有较深理解，能够无需 rd 帮助定位中等难度 bug，主动考虑类似问题在其它部分存在的风险 主动引入、介绍或交流新技术、工具或测试方法、流程，提高自身或团队的技术知识和能力 ; 并根据业务需要，推动项目组应用 能够根据工作现状，主动思考提高工作效率的解决办法，并产生实际效果 有意识使用现成 ( 而不是重新开发 ) 工具、解决方案 ( 或自动化、测试技术 ) ，降低技术实施成本 能够参与或负责跨产品线交流与合作 能够承担小组内公共事务或技术 topic; 能够对项目其他成员的测试给出有效的指导。 积极参与产品线内部讨论 ( 包括 QA/PM/RD)，并给出有价值的建议 ; T5 可以胜任子系统级别的测试