除了上篇说过的人员管理再有就是还要做好人员备份机制。组织过程资产的积累，也就是文档的传承，切记不可以有内容是保存在某些人的脑袋里面的，那么如果这个人不做这块业务了，这个人离职了，或者说是回头去看1年前，几年前测过的内容，是否还能记得呢？所以要注重文档的编写。

 

测试项目管理

 
1，整体最优思维
项目三角形包括范围、时间、成本、质量，当你拿到一个需求的时候，要清楚这个需求的最重要的一个目标是什么。
 
是想要快速上线？还是需要很高的质量，不能有一点马虎？那这个时候，针对不同的情况，我们就要采取不同的测试策略。需要快速上线的，我们可能有一些优先级低的问题，可以经过确认后，本次不修改，后续再优化；
 
如果质量要求高的，那么我们可能就要要投入更多的时间和成本。不可一味的追求完美，想要把各个方面全都做到最好，那样的话，可能会有资源上的浪费，同时又达不到满意的效果。
 
 
2，举一个我负责过的一个项目的例子
测试人员共5人，整个项目测试阶段由我来统筹。
项目周期2个月，共4个后端开发、2个移动端、1个前端及2个产品经理。
项目特点是项目周期长、业务复杂，可以把它分成了几个阶段进行：疏通测试、一轮测试、二轮测试、三轮回归。
 
结构化思维：针对上面的4个阶段，每个阶段的侧重点是不同的。不管是测试内容，还是测试管理方法上：
 
测试内容上：
在疏通测试阶段，不需要所有人员介入，只需要1-2人就可以了。
一轮测试主要是执行用例，将基本的场景全部覆盖全。
二轮测试主要是一些复杂场景的测试+探索性测试。
 
测试管理上：
在一轮、二轮测试过程中，这个时候的重点是把控质量，所以在项目时间上，不要对成员的测试时间要求太紧，希望他们有时间思考，有时间将想要测试的内容都测试到。但是要把控住时间节点。
 
三轮回归时，这个时候已经不是问质量的时候了，这个时候的重点是把控住进度，把这个项目的口子收住，甚至有些bug，这个时候发现的，就可以跟考虑留在后续再修复，因为这个时候如果修复问题的时候，又不断的引发新的问题，就会容易导致项目延期，很难在规定时间收住这个口子。
 
所以这个阶段会对项目跟进的更紧，更具体一些，重要bug的内容、影响、遇到的问题等。
 
人员管理方面：
针对不同的人，采取不同的管理策略。
 
本次的测试人员都是资历比我老的员工，这也是本次管理中的一个难点，要照顾她们的情绪，并且适时的想办法帮助她们解压，管理方面可以适当的放权，
 
让他们独立负责一部分，这样她们有成就感，也可以帮助我分担压力，我担任的是一个仆人式领导的角色。
 

经验总结

 

在项目中，避免不了的会遇到产品或开发或测试是新人的情况，这样的情况，最好开发或产品或测试，至少有一方，之前是做过相关需求，了解这个项目的。
 
当开发是新人的时候，开发遇到问题，可以引导开发提出他的需求。是需要产品讲解需求？测试的辅助？还是其他开发的帮助？
 
根据各种突发状况，我们要及时的调整测试计划。并且要从把控项目整体进度的角度考虑问题；在测试阻碍的时候，先进行部分内容的回归，保证了开发将阻碍问题修改好，测试完成后及时的上线。
 
作为测试Leader,可以只关注了主干逻辑，保证主要的内容质量，其他小的内容放权交给别人。切记不要凡事亲历亲为。
 
当你的下属，向你反馈问题时，一定要有响应，要么是跟她说明这个情况你是了解的，并跟她解释原因，把她说通；
 
要么是去解决这个问题；要么是向上汇报，共同解决这个问题。如果敷衍了事的话，他很有可能就将问题反馈到了你的上一级领导那里。
 
已知-已知、已知-未知风险都要采取规避措施，不能心存侥幸。
 
经过一段时间的团队协作、互相磨合，你会了解相关人员的一个特点，那么当我们接到一个新需求时，我们要关注开发、产品人员是谁，人员特点有哪些。
 
开发速度、开发质量、bug修改速度、bug修改的准确率怎么样，这个产品他以往的需求细致度等，是通常很完整，还是每次项目过程中都需要有大量的问题确认，或临时的需求变更。
 

了解到这些信息后，我们再根据这些信息，给出相应的估时和测试策略。
 
作为团队的管理者，不是单纯的任务分配者，不是所有的需求过来以后，立马分配给组员，让组员一个接着一个项目的赶进度，没有任何喘息的时间，应该张弛有度。
 
在自己这里做一道调节阀，可以评估下这个需求的紧急程度，在适当的时候把她分配给组员，比如说成员现在正在一个项目中，是不是在她完成整个项目后在把这个任务给她就可以？这样成员的状态、接受程度、工作效果都会更好。
 
而不是为了完成自己分配任务的工作，就将自己接到的任务，一股脑的分配下去。