QC：测试工程师(Quality Control)
定义：从职业角度来说，软件测试工程师是专门负责理解产品的功能要求，并对其进行测试的人员。他们的主要任务是检查软件是否存在错误（Bug），并测试软件的稳定性（Robustness）。简而言之，软件测试担当的是
质量管理角色，及时发现软件问题并及时督促更正，确保项目或产品的正常稳定运行。当然了，一个好的测试人员，对业务要有预判的梳理狙击和闭环，对开发要有质量的鞭策和提升，对项目和客户充分的背书。
⚖️ 履职规范
一、需求分析与测试计划
1. 需求分析与评审到位
场景：👀
在项目启动初期，测试工程师与产品经理、开发团队等利益相关者共同参加需求评审会议。会上，产品经理详细介绍产品的功能需求、业务流程和客户场景，测试则负责理解并验证需求的准确性、完整性和可测试性。基于评审结果，制定详细的测试计划，明确测试范围、测试策略、资源分配和时间安排，为后续测试工作提供依据。
这个场景是要确保测试团队对产品需求有深入的理解，能够准确识别测试重点，为后续测试工作输出做好扎实准备。有效分析和评审，狙击需求漏洞，支撑产品闭环逻辑和潜在质量问题。
🦴 输入
根据需求资料，产品需求文档（PRD）、原型设计与交互稿等。
🎗️ 输出
01-测试计划
2. 资源与环境准备妥当
场景：👀
在测试计划制定后，测试需要根据项目需求和测试计划，评估所需的测试资源（如测试工具、测试人员、测试设备等）和测试环境（如操作系统、数据库、网络配置等）。基于评估结果，制定详细的资源分配方案和环境搭建计划，确保后续测试工作能够顺利开展。
这个场景是需要测试伙伴，确保测试资源的合理调配和测试环境的稳定性，组长需要根据项目计划，测试计划，做好人员部署和具体测试工作安排，进出场时间，让运维支撑搭好测试环境并自行管理好测试环境，为后续测试执行做好充分准备。
🦴 输入
测试工作是连续性的，关联性的，比如这里就需要根据制定的测试计划开展后续工作。
🎗️ 输出
02-测试资源日历表|03-测试环境及服务器资源信息
二、用例设计与数据准备
1. 测试用例设计巴适
场景：👀
在需求评审和资源准备完成后，测试基于需规和原型开发设计文档，设计详细的测试用例。测试用例应包括测试目的、测试步骤、预期结果等关键信息，确保测试能够全面覆盖功能点和业务流程。
这个场景需要测试确保用例的完整性和准确性，为测试执行提供有力的支持，不要把这个做成流于形式的东西，为后续的用例库也应该做一些沉淀的意识和准备。
🦴 输入
根据评审、需规、以及开发设计文档作为输出用例的重要依据。
🎗️ 输出
02-测试用例（禅道）|03-组织用例评审
2. 测试数据准备
场景：👀
测试用例设计完成后，测试需要根据测试用例的需求，准备相应的测试数据。测试数据应尽量模拟真实用户场景，规避制造脏数据，应该模拟真实数据，确保测试能够相对比较真实反映功能的稳定性。同时，测试最好也制定详细的测试数据准备计划，确保数据的准确性和一致性，还是为了避免乱七八糟脏数据。
这个场景其实能很好的确保测试数据的尽量的充分和准确，我们不能因为各种原因的限制，被动的把这一份专业化的动作裁剪了，而是要想办法的去创造这样的便利和条件，以便测试角色更加直观的模拟真实的场景，并且对数据的流转有更敏锐的识别，狙击后端伙伴不经意的制造生产上的无效数据。
🦴 输入
这里根据测试用例，用例库，业务场景解读等等。
🎗️ 输出
04-测试数据准备计划|05-测试数据集
三、测试执行与缺陷管理
1. showCase 溜起来
场景：👀
项目开始以后，会按照迭代或里程碑切割进度，项目根据项目计划的红线时间，围绕自己制定的测试计划，确定好测试执行的时机，不能让测试跟着开发屁股后面兜兜转转，测试应该如何避免这种疲于奔命的伺候呢？当测试体量较大时，该如何集合优势兵力合而击之，分而奸之呢？啊哒哒
测试执行应该是预防，发现，督促解决，回归结束，最多周而复始一次，而不应该再这个执行过程中反复拉扯，那么就应该督促开发人员充分做好自测，卡好 showcase 环节，要求一次通过，showcase 不通过不得提测，不然同时开了 3-4 个项目，有限的测试资源应该如何调配？那么我们的测试就要提高意识形态，风险左移和预狙。
🦴 输入
这里根据测试节点，协助项目经理，倒逼开发按时进行 case ，并且记录，在项目测试计划 case list 中标明逾期状态。
🎗️ 输出
06-showcase 时间计划表（sheet总览）|07-showcase 记录表（sheet1-X）
2. 提测
场景：👀
showcase 动作完成以后，测试觉得木问题叻，准予提测，督促相关责任人应及时发起提测，把控要提测事项，版本咯，影响范围咯，分支咯，具体的内容咯等等。
测试如果自己都不重视提测环节，以及提测质量的把控，哦买噶，那你活该叻累死累活，我还嫌弃你辣样子，提测也不应该是一个形式，而是在提测过程中，帮助项目规避质量问题的同时，侧面督促了进度，再侧面也规范了协同和专业测的标准化细节，你版本是不是乱七八糟啊？你分支是不是奇奇怪怪啊？你影响范围是不是胡说八道啊等等对吧，怼人多爽？给你机会就把握住嘛。
🦴 输入
很明显啦，根据你的测试计划啦，到点了还通不过 case，不提测或达不到提测要求，红线在你这被动的红嘛？提前几天甚至一周就灌溉这个事儿啦，预测到爆雷提前滴溜他的 CodeMaster，组长，项目经理啦，让他们摆平啦对不对。
🎗️ 输出
08-提测申请单
3. bug 指派与回归
场景：👀
测试人员利用好禅道工具，在便利性的同时，测试自身也要做好专业输出，如何更加直观职业化的输出 bug，不要让开发看到 bug 单一脸懵逼不明觉厉，也不要 bug 指派完了就不管不顾，双方都尊重下项目时间红线，根据测试计划，跟开发明确解决时间。
标题顾名思义，描述快速锁定问题，复现操作截图一目了然，期望验证结果嘎嘣脆的清晰明了，让开发脑壳就一念头，能不能行，不行就赶紧想办法，风险提前爆出，协同解决。
🦴 输入
这个咩啥好讲的，根据测试梳理的业务流程，功能交互，测试用例验证点等，执行测试动作发现的问题等。
🎗️ 输出
09-bug标准化指派回归|10-bug当量表
关于 showcase => 提测 => 回归
最后补充一下，以上测试都要检查好喔，别随便什么乱七八焦的一个 excel，描述让舌头捋直叻写清楚，不行打回掉去，你要归档啦。还有啦，bug 当量表要带分析啦，抄送 CM，组长，项目经理，数据该咋样就咋样，莫要当面瓜啦，这不是帮他是坑他，你这样对做的好的人公平不啦，让他们职能角色做培养和提升啦，我也不要跟你啦啦啦很烦啦。
四、测试总结与报告
场景：👀
在测试执行和缺陷管理完成后，测试伙伴需要撰写详细的测试总结报告。报告应包括测试过程、测试结果、缺陷统计、经验教训等关键信息。同时，测试小伙伴还需基于测试过程中的问题和经验教训，提出测试流程、测试用例设计等方面的改进建议。
这个场景呢能确保测试工作的全面总结和评估，为后续测试工作提供了宝贵的经验和参考沉淀，精兵路线嘛。
🦴 输入
测试工作有个好玩的点，就跟 reduce 函数一样，当下的输入是上个节点的输出或者组合，如上面的测试执行记录、缺陷报告与修复验证记录等等。
🎗️ 输出
11-测试报告|12-测试改进建议
五、持续改进与优化
1. 测试流程与工具优化
场景：👀
在测试总结与报告完成后，测试伙伴根据测试总结报告和测试改进建议，持续优化测试流程，升级测试工具。优化后的测试流程应更加高效、准确，测试工具应更加智能、易用。同时，测试还需定期回顾和更新测试用例库，问题库，确保测试用例的时效性和复用性。
这个场景需要确保测试工作的持续改进和优化，为测试能效提供有效保障。
🦴 输入
测试报告、测试改进建议等等。
🎗️ 输出
13-测试工具升级方案
✨ 测试 Leader
测试负责人跟其他角色有些许区别，需要根据项目计划安排，动态调配资源，梳理和赋能小组伙伴，做具体的测试计划部署和执行引导工作，同时还要围绕部门整体要求下的，项目建设、专业提升及分享沉淀，以及标准化要求，培训管理等内建工作。
要求及期许：
由组长拟定小组管理体系和考核标准，明确小组的职责和目标，上报部门确认，最终完成小组管理标准化体系化落地，评审定版，版本管理，上传语雀，上报公司归档批复，部门对小组预期要求，应包括但不限于如下内容；
1. 管理思想
场景：👀
管理是一种行为和动作，执行的目的和过程，应该都有相应的理论作为指导和参考依据。认知，执行，验证缺一不可，我们的管理人员，需要做好角色转变，首先要提升和改变自己的认知，然后要去理顺章程，理顺了，再去说，人、事、物如何去有效调配管理，管理不能仅浮于表面，也不是某一个点的问题，而是基于面的，网状的，立体而发散的，要尽量的让自己知其然，知其所以然，用好的，优秀东西，同化和影响，引导，做这些之前，你可能需要深入了解被管理的人员，他们的能力，擅长的领域，工作的安排，专业的输入输出，优点以及缺点，甚至是他们的诉求和成长以及发展和价值。
那么作为组长，你要做人才识别，做一下小组的人盘盘点，你要有盘点的思路和章程，你对专业小组管理的理解，对同属性伙伴专业输出的识别，有一套方法论，基于这个方法论，针对动态的业务场景和公司战略需要，有人才分类匹配的依据，并且针对态度能力的融合，可以针对性的输出管理办法和考核标准，让大家知道需要把做的事儿，如何职业化的去做到什么程度，并把它的价值和能效体现起来，激活人才，凝聚一体，如臂指使。
🦴 输入
公司及部门对于专业组管理要求，年底公司各组织人员的人才盘点动作，但希望各负责人把这一块做的超出预期，莫要流于形式的交作业，而是真的在其位谋其政，有一些自己的思考，沉淀，总结和章程在里面。
🎗️ 输出
01-人才盘点章程|02-人才模型（方法）|03-人才分类（依据）|04-小组管理办法|05-考核标准
尔后由 TEC 小组参与评审后定稿公司级终审。
2. 管理动作
场景：👀
小组管理应该做哪些事情呢？应该有哪些事件源和动作协同呢？如何穿针引线的去引导和合力呢？对管理动作的执行，有哪些动机和预判呢？对于认知和能力，如何扁平化达成共识呢？我们的管理者，不妨好好思考一下，它应包含但不限于以下内容。
那么简单直白一点说，一线的管理动作是需要一些行为执行来拉通分工协同的，动作就是其中一个最直观的抓手；比如小组内部分享，识别擅长和偏好，优缺点，引导性和针对性的使成员共同成长；小组双周会，调动小组的集体力量和智慧解决点点滴聚焦的问题，以面破点，落地解决问题，体现赋能，也为后续的工作计划和人员调配有一个前置清晰的依据。
🦴 输入
可能是项目的刚需，可能是标准化体系的内建，可能是能力成长的需要，也可能是工作的把控、成员的援助诉求、业务支撑点的洞察、离散性的产品问题等等，不一而足；
🎗️ 输出
06-小组分享培训计划|07-小组双周会及成员问题跟进表
分享培训频次（至少月度 2 次），主题方向（项目疑难杂症，工作流，技术方案等等），分享资料归档并上传语雀，成员分享培训评价管理，汇总归档；
小组双周会，成员两周工作情况互通，遇到的问题，需要协助解决的事项，输出待解决事项清单（提出人，内容类别，内容详情，解决时间，解决人），上传归档及跟进解决，双周会不要求会议纪要，但是要有 成员问题跟进表。
3. 管理人员
场景：👀
部门计划将人员调配的权限，逐步下放到专业组负责人手里，后面组织结构的响应公司战略部署部门做动态调整，拉通专业组和项目组的高效协同，使小组管理者对成员工作有直观的洞察（能力/态度），建立 T 型管理梯队。
要做到人员的有效调动，第一，对成员能力和项目匹配度有认知和判定；第二，能识别项目计划制定专业计划，避免人员空闲稀释成本和能效；第三，把控项目上专业人员的风险，有补台补位及预防措施，并确定末尾红线替换淘汰机制（比如任务完成度和输出要做到什么程度）若因为组人员调配，影响到项目组工作计划造成时间冲突的，需跟项目负责人和项目计划达成一致（计划识别和同步），有分歧上报部门调整优先级（尽量避免）。
🦴 输入
人员的调动依据一定是项目计划和调动事件源，根据项目计划调动的人员安排，需上报部门记录和确认，同时，要去识别人员空闲率。避免忙的忙死，闲的闲死，后续根据职级跟指标相挂钩。
🎗️ 输出
08-项目人员配置表|09-资源日历表
4. 培养和晋升
场景：👀
每个人的认知，能力，经历，沟通力，理解力，学习力都不一样，我们的管理者，如何把这些基于点的优点，树立榜样，作为标品和基线，提升和补缺典型的缺点，并且在这个过程中，为组织产出和留存，可识别的，直观的，有价值的沉淀，思考，和创新。比如一个产品，方案编写和演讲的能力，就是一个典型，如何去培养典型的能力。
回归职场，职业发展的路径，公司团队发展的需要，内建都是核心，练武不练功，到头一场空，培养和晋升是相辅相成的，通俗直白一点说，你要晋升，就培养出来一个人来可以替代你现有，要把价值显性化，实例化，具象化，这才是管理的价值，赋能使能。
小组成员能力培养，要定指标，定要求，有培养计划和课题，结果可验证，如业务域，演讲能力，方案能力，需求管理能力等等，用输出沉淀和结果说话（也会作为晋升依据）；专业管理人员，需跟成员明确梯队匹配分级，未来我们配合人力资源把人员职级细化，明确晋升路径。
Core
TIP
对于一个合格且优秀的组长，一定要是制度流程的坚定拥护者和执行者，上传下达，上行下效，尽力尽心尽责的做好职能管理，树立好的标杆典型，杜绝劣币淘汰良币的情况发生，所以在这个过程中，就要做好检查，有效监督，积极纠偏，努力去做提升。把事、人、情分开来看。我们的组长，不但要对项目的输入输出有哪些洞若观火，还应该对输入输出到什么程度了如指掌，再好的制度、流程、规范，没有检查监督，纠偏和优化，最后就会不了了之流于形式。管理角色需要提升自己的认知，打败自己心理的矫情和软弱，规避本位主义的趋利避害，才是迈向管理角色坚实的一步，应该用更健康的心态去看待和开展管理工作，最终的目的，都是为了精益赋能，降低沟通和试错成本，而不是为管理而管理。