如何做好软件测试项目管理?看这篇就够了!
一、如何做好测试管理?(上篇)
（来源网络）
今天这个主题，我想从两个方面来分享，分别是测试人员管理和测试项目管理。
了解不同人员各自的特点，采取不同的管理方法，举几个例子，
比如有的员工能力强、本领大，但是不喜欢跟人合作，喜欢单打独斗，这是典型的孙悟空式的员工，这类型的员工就可以考虑让她独立负责一个项目，她可以完成的很好，又避免了跟别人的冲突。
还有一类员工，她们可能刚刚毕业，还没有形成自己的事业观，没有什么事业心，每天的工作基本是混的状态，这类员工可以有两种管理方式：
第一种就是采取规定任务截止时间节点的方式，也就是说我们帮她做好任务规划，之后明确的告诉她，截止到某一时间点应该完成的任务内容，这样的话，如果完不成她要自己想办法，也就避免了白天的打酱油状态；
另外一种方式，还可以让她自己说，这个任务大约需要多长时间，如果觉得合理，则对这个时间达成一致，利用他人自承诺这一点。并且，对于这类员工的进度监控，要更频繁一些。
还有一类员工，她们的能力不错，沟通协调、与他人共同合作的能力也很好，这类员工就要适当的放手，相应的进度监控要宽松些，可能每天晚上问一次进度，或者几天，或者接近项目截止日期时，再询问下是否有问题。
当你刚刚坐上测试管理这个岗位的时候，需要对你下属的管理严苛一点，否则的话，对内无法树立威信，对外无法交付好的产品质量，同样也得不到信任和认可。
但是，当经过一段时间的洗礼后，团队成员已经被培养成强兵干将了，对外也已经取得了足够的信任和认可，那么这个时候就要把重心放在维稳上面了，维稳其实就是抓住核心员工，降低部门的离职率。
当你坐上管理岗位的时候，你的心胸需要更加广阔，你的包容度要更强，比如说我上面提到的孙悟空式员工，他们还有一个特点就是会比较孤傲。
这个时候作为领导，就不能因为你不喜欢她的性格，看不惯她的一些做法，而把她逐出你的团队。
因为对于很多公司其实招聘一个能力强，能把工作做的很好的员工并不是一件容易的事，这个时候要想的就是把她放在合适的位置上。
作为一个管理者，要充分的了解你的下属，这个了解不仅仅局限于工作、性格方面，还需要了解他的生活方面，只有这样，才能全方位的把控这个人，在适当的时候，采取适当的策略。
举几个例子，比如上面说的维稳方面，当你了解你的员工，最近在做什么，比如他最近想考一个证书，在紧张的备考，并且已经临近考试了，这个时候就可以适当放宽对他的工作任务的安排，减少他的加班，让他在考试结束后，在帮其他同事多分担一些；
比如了解到某位员工最近家里遇到了一些事情，这个时候也可以对他的请假通融一下，对他家里遇到的事情表现出关心或是给予一下帮助，也就是在他有困难、有需要的时候，你能够帮上一把，这个员工会对你很感激，大大提高他的忠诚度。
也就是说，要掌握好对他工作上严厉，和对他生活上的关心之间的平衡。
二、如何做好测试管理?(下篇:项目管理)
（松勤 松勤软件测试）
除了上篇说过的人员管理再有就是还要做好人员备份机制。组织过程资产的积累，也就是文档的传承，切记不可以有内容是保存在某些人的脑袋里面的，那么如果这个人不做这块业务了，这个人离职了，或者说是回头去看1年前，几年前测过的内容，是否还能记得呢？所以要注重文档的编写。
项目三角形包括范围、时间、成本、质量，当你拿到一个需求的时候，要清楚这个需求的最重要的一个目标是什么。
是想要快速上线？还是需要很高的质量，不能有一点马虎？那这个时候，针对不同的情况，我们就要采取不同的测试策略。需要快速上线的，我们可能有一些优先级低的问题，可以经过确认后，本次不修改，后续再优化；
如果质量要求高的，那么我们可能就要要投入更多的时间和成本。不可一味的追求完美，想要把各个方面全都做到最好，那样的话，可能会有资源上的浪费，同时又达不到满意的效果。
项目周期2个月，共4个后端开发、2个移动端、1个前端及2个产品经理。
项目特点是项目周期长、业务复杂，可以把它分成了几个阶段进行：疏通测试、一轮测试、二轮测试、三轮回归。
结构化思维：针对上面的4个阶段，每个阶段的侧重点是不同的。不管是测试内容，还是测试管理方法上：
在疏通测试阶段，不需要所有人员介入，只需要1-2人就可以了。
在一轮、二轮测试过程中，这个时候的重点是把控质量，所以在项目时间上，不要对成员的测试时间要求太紧，希望他们有时间思考，有时间将想要测试的内容都测试到。但是要把控住时间节点。
三轮回归时，这个时候已经不是问质量的时候了，这个时候的重点是把控住进度，把这个项目的口子收住，甚至有些bug，这个时候发现的，就可以跟考虑留在后续再修复，因为这个时候如果修复问题的时候，又不断的引发新的问题，就会容易导致项目延期，很难在规定时间收住这个口子。
所以这个阶段会对项目跟进的更紧，更具体一些，重要bug的内容、影响、遇到的问题等。
本次的测试人员都是资历比我老的员工，这也是本次管理中的一个难点，要照顾她们的情绪，并且适时的想办法帮助她们解压，管理方面可以适当的放权，
让他们独立负责一部分，这样她们有成就感，也可以帮助我分担压力，我担任的是一个仆人式领导的角色。
在项目中，避免不了的会遇到产品或开发或测试是新人的情况，这样的情况，最好开发或产品或测试，至少有一方，之前是做过相关需求，了解这个项目的。
当开发是新人的时候，开发遇到问题，可以引导开发提出他的需求。是需要产品讲解需求？测试的辅助？还是其他开发的帮助？
根据各种突发状况，我们要及时的调整测试计划。并且要从把控项目整体进度的角度考虑问题；在测试阻碍的时候，先进行部分内容的回归，保证了开发将阻碍问题修改好，测试完成后及时的上线。
作为测试Leader,可以只关注了主干逻辑，保证主要的内容质量，其他小的内容放权交给别人。切记不要凡事亲历亲为。
当你的下属，向你反馈问题时，一定要有响应，要么是跟她说明这个情况你是了解的，并跟她解释原因，把她说通；
要么是去解决这个问题；要么是向上汇报，共同解决这个问题。如果敷衍了事的话，他很有可能就将问题反馈到了你的上一级领导那里。
已知-已知、已知-未知风险都要采取规避措施，不能心存侥幸。
经过一段时间的团队协作、互相磨合，你会了解相关人员的一个特点，那么当我们接到一个新需求时，我们要关注开发、产品人员是谁，人员特点有哪些。
开发速度、开发质量、bug修改速度、bug修改的准确率怎么样，这个产品他以往的需求细致度等，是通常很完整，还是每次项目过程中都需要有大量的问题确认，或临时的需求变更。
了解到这些信息后，我们再根据这些信息，给出相应的估时和测试策略。
作为团队的管理者，不是单纯的任务分配者，不是所有的需求过来以后，立马分配给组员，让组员一个接着一个项目的赶进度，没有任何喘息的时间，应该张弛有度。
在自己这里做一道调节阀，可以评估下这个需求的紧急程度，在适当的时候把她分配给组员，比如说成员现在正在一个项目中，是不是在她完成整个项目后在把这个任务给她就可以？这样成员的状态、接受程度、工作效果都会更好。
而不是为了完成自己分配任务的工作，就将自己接到的任务，一股脑的分配下去。
三、谈谈测试项目管理
（原创 ruxue fengruxue）
工作这么久以来，接手测试的需求也非常多了，有持续了一整年的重构性的项目，有从0到1 的维持半年的创新型项目，也有小型的持续数周的需求，还有一些日常的快速迭代，大部分时候，做为测试TPM（Tester Project Manager）,需要制定整体的测试计划，包含了测试策略，测试时间节点，各域联调计划以及各种专项例如自动化，稳定性，性能，多语言，APP端还有各种兼容性测试，弱网测试等的进度跟进。TPM要做的事情很多时候取决于项目的时间，大部分情况下很多测试专项的事情比如稳定性，资损防控需要大量人力投入的，往往不是跟随项目的进度一起的，但是如果是项目的增量需求，可以借助做项目的契机把这些事情给一起做了。
项目管理其实是一个比较大的范畴，毕竟项目管理还是一个单独的岗位，项管主要职责主要是在拉通业务，产品，技术的人力资源分配，各域开发交付节奏是否match整体业务目标等，但是对测试相关的细节还是需要专人去跟进。下面从我自己做过的项目中总结一下，从测试TPM的角色说说在项目交付中需要关注的点。
常见的测试项目管理中会遇到的影响项目如期交付的问题：
1、研发阶段：需求变更、测试没有提前介入解决可测性问题
2、测试阶段：各域测试时间没有对齐、开发提测质量不过关、测试环境等问题导致测试时间比原定时间长
3、灰度发布阶段：业务验收不通过、缺失灰度过程测试验证方案等
整个项目节奏其实主要可以分为三个阶段：准确阶段，实战阶段，灰度发布阶段 ，其实也就是研发阶段，测试阶段，发布阶段，不同的阶段侧重点不一样，我个人理解，最重要的还是在准备阶段需要提前做的事情，这个直接决定了最后项目是否能够按时按质交付。
我个人认为比较重要核心的是：测试提前介入，深入了解需求，挖掘可提效点。
项目测试的需求贯穿了业务测试真个工作阶段，一个需求接手要怎么做其实已经有了比较固定的流程，从需求评审-> 技术评审->测试用例评审–>测试执行->稳定性布防->灰度发布->线上交付验证 整个需求交付周期，有些节点要做的事情和自己所处的公司业务小组风格关联比较大，一般都是比较固定的，如果要把这个需求做出不一样的创新点，那么就需要深入了解需求，协同产品研发一起挖掘整个过程中可以提效的地方或者测试开发可以提前做的地方，比如资损场景梳理，监控布防，全链路强弱依赖梳理等。
准备阶段核心两件事情，协同规范和测试方案制定 ，协同规范的制定保障了不同业务组测试之间的沟通协作方式和时间节奏，有些项目还需要和外部第三方公司测试例如资金业务需要对接各大银行，对方测试流程可能会有较大差异，为此，提前拉通各域测试对齐整个项目节奏，确定联调介入时间点为首要任务。
当需求正式进入测试阶段之后，比较有用且有效的一个节点就是需要严格把控开发的提测质量，例如可以通过测试提供冒烟用例或者研发提测演示的方式，来保障开发提测的功能是符合需求描述的，这可以避免后续开发测试的反复沟通，也是测试质量左移的核心一part 。
在整个测试阶段，当遇到没评估到的卡点的时候，及时暴露风险，同步到项目组的人，快速决策推进卡点解决。
(KANO模型，一个评估需求优先级的模型，是不是同样也可以用在问题处理优先级上面，那些是迫切能够解决用户问题的，那些是可以滞后解决的的。)
需求发布上线之后，后续还有各种线上验证，圈客迁移，切流灰度，全链路线上压测等，风险大，需要提升问题主动发现率减少客诉，问题应急SOP达标，其他非紧急问题也需要做好问题追踪改进机制，及时复盘跟进。
不同周期的项目需要完成的事情不一样，周期长的需要在项目的过程中把一些基础能力给先完善了才能带来后面的提效，周期不同，侧重点会有所区分，需要保障合理ROI。
1.半年以上项目周期
大项目在管理的过程中，如果各种节点都需要通过人工去跟进的话，那么效率是极低的，目前在公司的devops 实践已经比较完善的前提下，其实从需求管控，变更管控，迭代排期等平台的能力基本都可以支撑，但是具体到测试管理上面，如何从项目的角度去看整个需求的测试进度，bug修复情况，风险点以及各个测试专项的进度，比如资损防控，故障演练，性能压测等，各业务域之前达成一致的专项完结的进度如何了，如果这些进度全依赖测试TPM 人工跟进，效率会极低且不利于后续的问题复盘。
所以，针对测试流程的质量标准线上化就显得尤为重要。这种项目管理方式其实用在了当时两个从0到1的创新项目上，效果还可以,除此之外，还需要持续同步项目进展，通过周报，月报等形式同步到项目组成员。
这类需要持续数周的项目很多情况下需要协同和自己日常强相关的几个域来一起交付，像自己现在所做的资金类项目，就涉及到外汇，结算，网关，账务，第三方银行渠道的联调配合。 个人认为要按时按质交付，在多个节点中，以下几点尤为关键：
1、联调节奏提前确认：拉通各域测试能够投入测试联调的时间，尤其是外部第三方的配合时间节点，有些银行渠道他们的是固定每个月发版一次，如果错过了这个交付节点，就要等到下一次，这个就存在严重的项目延期风险了。
2、联调用例评审： 如果说各域的测试细节都要全员参与的话，效率会偏低且效果不一定好，但是核心场景的联调用例还是需要全员包括业务，产品，技术，测试一起过一轮，保障核心功能是能够如期交付的。
3、测试日报同步：月度周期的项目其实往往测试时间投入只有一周左右的时间，时间一般都比较紧凑，所以需要规划好每天的项目进度，及时跟进同步风险问题，保障项目准点交付
4、业务验收 ：需求交付产物是否符合业务产品诉求需要最后让业务产品验收一轮，不同的业务组和项目会有些区别，有部分是在预发布进行验收，有部分是在线上验收的。
日常迭代小需求包含两类，一类需要测试接手的，一类是开发自测的，研发自测的需求测试review一下自测文档，补充是否需要让开发新增的测试场景，然后做好相关的自动化基建基本可以保障交付质量。
测试接手的需求，改动不大的基本只是涉及到自己域的改动，这个按日常需求接手规范来做即可，这类型的需求其实也可以用质量标准化流程管控。
1、如您转载本公众号原创内容必须注明出处。
2、本公众号转载的内容是出于传递更多信息之目的，若有来源标注错误或侵犯了您的合法权益，请作者或发布单位与我们联系，我们将及时进行修改或删除处理。
3、本公众号文中部分图片来源于网络，版权归原作者所有，如果侵犯到您的权益，请联系我们删除。
4、本公众号发布的所有内容，并不意味着本公众号赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本公众号证实，对本文全部或者部分内容的真实性、完整性、及时性我们不作任何保证或承诺，请浏览者仅作参考，并请自行核实。
夜雨聆风
