百度测试工程师胜任力模型

　　百度测试工程师胜任力模型（任职资格标准） - QAD & QAT
　　胜任力模型说明：
　　胜任力模型作为QATC职称评定标准的细化与解读，帮助QA更好的理解各职称级别对于工程师的能力要求。
　　细则中对各级别工程师，在四个维度上的要求是and的关系；每个级别的单维度下有多条能力描述，这些描述也是and的关系
　　从胜任力角度看，这四个维度同样重要，理想情况下各级别工程师需要达到所在级别四个维度的所有要求；但具体在职称评定过程中会根据工程师的技术特点和项目背景，在四个维度的要求上有所侧重
　　高一级别（比如：T5）的职称要求，包含所有低于此级别(比如：T3/T4)的职称要求
　　文中所说的“能够”“胜任”等字眼，是强调工程师的能力；而不是要求工程师一直做这些事情; 限于篇幅，本文也不对“能够”“胜任”等的衡量标准进行解读，终解读权在QATC
　　Q&A:
　　问：该文档有什么用处？
　　答：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
　　可以胜任子系统级别的测试方案、自动化方案的设计（包括该子系统下所有模块测试方案的设计以及整个子系统架构的测试方案的设计），工作质量很高；能够合理引进新技术、新工具；能够很好的指导、 评审测试工程师的测试工作。
　　在项目计划阶段，能够与RD/PM合作，在项目计划、优先级、功能等问题上，结合质量与效率要求，作出适当的项目策略
　　在项目设计与编码阶段，能够评审RD设计实现，并提出有效建议；同时考虑可测性需求，并推动实现
　　在测试设计阶段，能够编写合理的项目测试方案，指导项目测试得执行；
　　在测试开发阶段，能够调研、开发或应用可靠的自动化测试于项目，考虑现有方案降低技术成本，并产生较好的效率提升或质量提升效果；
　　在项目实施中，能够利用代码评审或覆盖率分析工具，在早期发现更多代码与设计上的bug，并评估测试风险，改进测试方法，提高产品测试覆盖率
　　评审产品、设计或测试文档，提出关键性建议并实现，使得产品易用性、可靠性等各方面得到提高
　　能够结合使用反馈，给产品提出建议并得到实施
　　能够关注产品整体质量或评测
　　对产品设计和实现有较深理解，能够无需rd帮助而调试大部分bug；对bug修复给出有价值的意见和建议
　　能够利用竞争对手信息或业界趋势，增强所在组的产品功能或项目工作
　　对于组内复杂问题，能够分析各种方案的优缺点，并给出合理化的解决建议
　　结合PM/RD产品技术规划（项目经理级），能够制定对应的测试技术规划，并取得成果
　　有意识的与周边部门建立良好个人关系
　　能够负责项目经理团队内公共技术事务，并取得较好成果
　　能够指导工程师的技术创新和测试工作
　　T6
　　具有较强的子系统级把握能力，能够主动发现和解决测试关键问题。能在需求评审阶段改进被测系统的可测试性。能发挥一定的技术影响力。在某种测试方法或者测试技术有着较高的技术水准。
　　在项目调研阶段，能够建议或评审产品技术方案，并得到项目组成员认同
　　在项目设计阶段，能够参与子系统级产品技术的评审，考虑可测性与用户反馈，并推动实现，有效提高产品的用户体验与质量
　　在测试设计阶段，帮助团队成员评审测试用例设计，能够优化用例设计，降低用例冗余，节省测试时间
　　在测试开发阶段，能够判断并主导开发或改进测试工具或测试自动化，使之广泛应用于经理级团队（或更广范围），并产生较好的效率提升
　　能够被内外部用户或合作部门（RD/PM/FE/OP等）认同为所在产品领域的技术问题解决专家
　　对产品和用户深入理解，能够帮助判断产品或功能发布的优先级
　　根据用户反馈或调研产出，推动项目计划和方案，从而解决用户问题
　　能够分析漏测bug，确定问题根源并给出补救措施（如引入新的测试方案、技术等），降低此领域的漏测率
　　对产品线存在的问题（包括产品、架构设计、测试方法等），能够给出合理化解决建议，并取得成果
　　能够给出某领域（如：性能测试、安全测试、web测试等）测试方案，并得到广泛应用
　　能够负责或参与产品组（RD/PM/QA/FE/OP）的公共事务（如产品技术topic，流程，敏捷等），并取得较好成果
　　能够负责经理团队内技术工作（如：公共技术事务），并取得较好成果
　　T7
　　在某个专项领域有着一定的技术水准。能对解决测试技术难题做出较大贡献。能够有效落实技术创新的想法来提高测试质量和测试效率。
　　在产品规划或产品调研阶段，能够参与决策产品技术方案，积极提供有效建议，得到团队认可并且实施
　　在产品设计阶段，能够主动与RD合作，改进子系统级产品代码设计，大幅提高子系统产品质量
　　在产品测试计划阶段，能够创建产品质量体系（如：评测、流程、checklist等），帮助实现产品质量目标，并能够被其他合作方（如：PM/RD）所认同且执行