俗话说得好，不经历风雨怎么见彩虹，不被坑的领导不是真正的领导。测试工作是一门跨学科的工作，想成为一名优秀的测试管理者，除了具备跨学科的综合技能外，在制定工作流程和规章制度中一定要遵循可实施，可监督，可统计，可归纳等基本要素，如何做到这一点呢，我认为不防从如下方面多多思考和历练。
首先测试的类别繁多，平常所说的功能测试，性能测试，压力测试，冒烟测试，回归测试，平台测试（SDK、Web，GM工具等等）就琳琅满目，不胜枚举。作为一个测试管理者，可根据团队实际情况（如人员多少，团队整体技术力量，测试环境等），合理的划分测试类别和内容。把功能和关联性强的接口日志等放在测试组中测试，把关联性较弱的如性能，平台兼容性，SDK，单元测试等放在平台组中去测试。这样可以充分发挥团队的效率。一旦测试任务和测试资源确定后，可以通过如下的步骤来具体实施。
这里我把质量管理的工作拆分为如下九个过程来具体展开 -
- 软件质量管理的九个方面
1. 需求管理过程 -
我认为测试人员至少要关注这些方面
○ 评估需求的合理性 - 不是100%的接受需求描述，哪些不合理的需求，哪些值得优化的地方，需要及时的指出
○ 思考测试难度和测试周期 - 梳理需求时要尽量考虑每个功能点的难易度和评估所需时间，对于那些不能测试，或者测试难度很大的地方要及时提出，并和相关开发人员沟通解决方案，尽量做到全面，准确的评估。有利于后续的计划安排。
○ 思考关联度 - 是不是全新的功能需求，是否与已有的功能有关联，是否需要测试性关联的功能点。这也是在需求管理过程中值得关注的地方。2. 计划管理过程
这个过程中核心就是时间，每个环节的时间预估越准确，则项目的可控性越高，反之，则会导致各种不可预估的延期。作为测试质量管理者，可从以下方面来考量计划的制定3. 任务分配过程
从这几方面来考虑
4. 执行管理过程
关注和监督执行情况，了解动态信息，发现可能导致结果达不到的苗头要及时作出调整，或增加人手，或调整任务，或修改预期方案等等。5. 反馈管理过程
任务信息孤岛的出现会给项目带来潜在的风险，所以不要关起门来做测试，要及时的沟通，协调，不仅要知道自己在干什么，也要知道别人在干什么，也要让别人知道你在干什么。
6. bug管理过程
Bug管理最常见，也最容易被大家忽视。在这个过程中，我们需要关注八个方面，见下图：
其中bug数据分析，可以帮助我们清楚地了解，哪些模块，哪些开发人员容易出错，推进TDD模式，也许可以从此展开
7. 版本管理过程
○ 版本内容 -该进版本的内容必须进全，不该进版本的内容必须不进。这句看似废话的描述，实则是各种血泪史的控诉。版本中无论是少内容还是多内容，都会导致bug的出现。发版本前，多花一些时间，检查和控制好版本内容，则完全可以避免这一类问题的出现，做到防患于未然远比出了问题再修改要好的多。
另一点则是，任何内容的提交都需要经过测试，这条也是蹚了无数的雷才形成的流程。任何自认为代码没问题就提交而未经过测试的，往往是频繁出bug的地方。
○ 版本时间 - 为什么版本时间这么重要？晚一天发布不行吗？真实的答案是不行。任何跨天的延期发布都可能导致游戏内众多的活动内容调整，官网内容调整，更不用说昂贵的广告费用打了水漂。所以版本时间一定要控制好，尽量提前预估好时间，留出充足的时间来准备发布。
○ 其他 - 除了上述2点需要注意的，版本管理还需要注意兼容、版本纪录和版本发布后的线上监控等琐碎问题。8. 文档管理过程
文档管理重要程度看似鸡肋，而往往则是这个鸡肋能关键时刻救你一命。一个项目周期越长，如果没有详细的文档纪录，还有项目人员的变动，可能到项目后期都没有一个人能清楚某些规则。对于测试也是一样，需要做哪些文档管理呢？见下图：
还是那句话，传承做不好的项目不是好项目。9. 部门沟通协调管理过程
在现在项目过程中，协调部门间的资源越发重要，这基于两点现实：
○ 任何个体都无法保证项目质量。
○ 资源具有稀缺性，需要协调一切可利用的资源为己所用。
怎么做？一句话，沟通，不断沟通，玩命沟通。
踩过了无数的坑，才能明白做好项目的质量保证工作并非易事。趟了无数的雷，才能将一条条血泪总结成经验流程。
