测试工作的自我修养及流程

源自Gameres


如题，列条详述。
1.辅助过程裁减、细致化、明确项目规范.清晰产品在面向最终用户时的形态，对策划案（产品需求）中阐述不清晰或者有逻辑冲突的地方提出质疑.实际开发中，程序员受限于工作的焦点，所以QA/QC人员必须做到更了解产品将要达到一个什么样的形态，期间QA/QC人员的思路应保持在最终用户的身份上，而非开发参与者。
要求:
仔细阅读策划案(产品需求)
对阐述不清或者产品需求本身逻辑冲突所导致的疑问，要求做出释疑
依照开发目标，清晰该开发阶段产品的目标形态，以及与最终形态的差距

2. 制定〈质量保证计划〉参考相应的产品策划案，严谨斟酌产品需求的合理性以及大胆假设在即定需求下有可能产生的BUG，以此制定出质量保证计划（测试流程）产品将要实现的功能必须严格遵守产品需求，对于产品需求本身的合理性以及需求中所忽略的重要缺憾及时的对开发团队提出见解
要求:
确保《质量保证计划》严格的依照产品的需求
对需求合理性及缺憾性需求提出成熟的见解
制定出完善的质量保证计划，测试流程中不仅要保证每项功能的实现还必须最大程度的假设可能出现的情况

3.产品检查.确保产品在严格依照策划案（产品需求）实现了有效功能的同时，最大力度的保证实际开发人员所未预料到的BUG得到如实的反馈.依照制定的《质量保证计划》严谨的落实测试项，并且如实详尽的以书面形式（BUGZILLA）反馈。
要求:
遵照已有的测试计划完整的进行测试
参考现有产品需求，以用户的角度斟酌是否合理和完善，并且如实向开发团队反馈成熟建议
在确保测试流程完全落实，并且所有已知BUG已经反馈的情况下，进行大量重复性的测试。（就公司产品而言，就是反复玩，实际工作中，仅仅有30%左右的BUG是在预先制定的测试流程中可以体现的，其他大部分BUG在无序测试中反而更容易被侦测到）
未预料到的BUG出现，则总结该BUG的类型，并且将非偶然性的BUG添加入《质量保证计划》中。偶然性BUG权衡后记录。见注①

4.过程审计 统计反馈BUG的隶属对象 明确BUG会将由谁来处理，并且依照项目进度对BUG划分优先级
要求:
明确BUG的处理方，并且在BUGZILLA中指定正确的对象（不排除A的代码出现的BUG将由B处理的情况，具体实际对象应参考项目进度或服从安排）
明确目前的进度下将要处理的BUG
将反馈BUG的ID对应告知相应的开发人员

5.跟踪问题处理.根据项目的实际开发进度，跟踪已知的产品BUG处理情况.已处理的BUG经过反复测试后，及时反馈。
要求:
重复产品检查过程
核实BUG是否完全处理，以及最大程度的保证没有延伸BUG
及时在如:bugzilla中反馈BUG目前状态

6.度量及报告.资源有限的情况下，面对多个项目或者单元需要测试，QA/QC人员需要评估并且如实反馈。
要求:
在项目进行中，有核心部分需要有较大的把握保证其稳定性，在人力和时间资源有限的情况下，将精力更多的花费在此方向上，对于整个项目来说，是更优选择

7.经验积累 自身的工作经验的累积以外，对日渐成熟的工作方式及流程做书面保留，以实现公司非物质财富的累积
注①：偶然性BUG的处理在权衡后，明确其产生环境并加以记录。如：使用不同引擎开发的产品 开发环境的不同其偶然性BUG总有着必然联系，对此加以记录方便后续工作者的快速任职。