2、任务分配
总任务量：按照新功能模块或受影响模块，编写用例的数量，执行
测试用例的总量，测试工具开发量，背景知识
学习时间量，配合别的团队的
工作量
任务重要等级：核心模块功能，测试难度大的模块，改动较多的模块--》改动较小、影响较小的功能--》未受影响模块功能
人员等级、能力及时间：人员能力等级、技能，每个人工作量（人天），每个人按照每天6小时的工作量评估。
时间任务人员平衡：达到团队中人员的工作量相近，难度与人匹配，同时考虑不同层级每个人的发展，工作积极性及意向，及做相应的风险预防。
任务职责：约定每个人的工作内容，做到责任清晰可追踪，边界地带责任到人不出现扯皮现象。
发布人的职责---》项目中指定或固定人员,版本控制严格保证测试环境的正确性，记录测试发布中的相关点
需求用例人员--》需求到模块化之间出现的需求的确认变更跟踪及用例的补充 由 功能的模块化测试阶段人员负责
用例执行及bug--》按照分配的功能模块执行用例，提交bug，等待bug修复且版本发布后，验证bug及相应功能点，持续追踪直到被解决。通过bug平台查看bug量及相应的严重等级，大致了解软件的质量及测试人员的执行状况及用例覆盖度。
用例编写人--》基本按照模块化谁测试谁编写的原则，也可作相应调整，根据时间及工作量调整。
用例复核--》任务中指出相应的功能的复核人，做到交叉复核，复核后的结果email组内发出，相应用例编写人员补充修改用例。中间可以通过查看邮件内容得知大致情况（用例编写人的工作，用例复核人的工作）。
用例评审--》由用例编写人发起会议邀请，在规定时间周期范围内，组员自行调整安排，但是需要督促执行。
人员风险预防：
平常观察-->人员的动向（是否经常出去接打电话，请假），对待工作的态度有无转变、工作情绪
沟通了解：通过面对面的沟通了解，通过其他同事口中获取
分析：薪资与技能是否匹配，工作兴趣及意向，人际关系情况
3、任务执行及监控
任务执行进度、质量（如何检查）
每个任务阶段的监控手段：
需求阶段：需要组员用邮件的形式发出需求中存在的问题及疑问点，通过查看邮件中的内容，得知组员研究需求的程度（全面性及深度）。前提是经理要对需求了解深入。
用例编写：将每天编写的用例发布到用例平台上，每天站立汇报工作进展。前提是需要有一个用例平台可以统计发布组员的用例数量。
用例执行：通过用例平台执行用例，通过平台统计每日每人的用例执行数及阶段内的总量，从而来确定当前的执行进度。用例的执行质量，是否遗漏或测试不全，可以通过经理抽查或在回归测试阶段，出现的相应的bug来分析总结（按理说不应该在回归阶段出现的bug及bug总量分析），从而来确定模块化测试人员的质量。
bug量：通过bug平台，每日发布组员的bug量（bug所处的阶段及严重程度及有效性），通过bug的质量就可以组员的测试状况及工作能力。测试经理可以通过bug总量及修复状况，督促开发团队配合解决。同时抄送开发及需求团队（可以建立一个虚拟邮件组），起到督促开发解决bug的目的，同时也让开发经理了解开发的质量及解决bug的进度，同时也让需求人员了解当前的软件质量及测试的工作量，从而对以后要是出现项目延期提供数据依据。前提是搭建一个bug平台，需求开发测试都有相应的查看权限。
用例评审：通过需求讲解，从而知道组员的需求理解状况，是否偏离或出现误解，需要细致知道每个细小功能点的内容，用例中是否有覆盖，从而进行风险预防，从而也可知道组员的需求理解能力。
用例复核：组内人员交叉复核，邮件通知组内复核结果，测试经理需要关注邮件内容，得知组员的用例编写能力，并也要持续跟进用例补充情况。
其他手段：
例会：组员给出今天所做任务，明天所作任务，今天任务过程中遇到的问题
软件功能未实现或质量较差影响测试--》测试经理需要督促开发解决问题（并给出解决时间点）或让组员养成自己去督促开发解决的习惯，让此作为一种工作积极性的考核。测试经理也需要分析问题的严重性，然后和相应的开发经理进行沟通，找到问题根源，以便减少此类事情出现的概率。
有别的任务插入需要解决--》经理需要根据两个事情严重程度进行分析，然后进行调整。别的任务严重，先处理别的任务，同时任务量及时间上可以做些细微调整。如果不重要，可以先放放。
工作量太大预估时间不够--》组员需要给出具体的原因，bug太多，还是技术难度大，还是组员自身的技术水平能力不够。经理需要分析原因，并协助解决问题。
其他事情请假影响进度--》尽量加强组员的工作积极性，并养成一种工作习惯氛围，自己的事情尽量自己做好，每个人有每个人的工作量，每月的请假量也作为一种考核方式。
观察：通过平常观察或邮件反馈，详细分析并及了解当前组员工作内容，查找缺失点及风险点、进度是否与预期偏移，及时发现督促并解决。
