手游测试的思考-研发期（随笔）

现在所处的研发期项目，目前遇到的问题有以下几点

• 测试环境的不稳定，造成测试干扰
• 版本质量标准不明确，QA无法自主判断缺陷是否该提成bug
• 研发流程混乱
• 修复bug时间安排混乱

简单先总结几点问题较为明显的。接下来对于上方几点进行一一思考。

• 测试环境的不稳定，造成测试干扰。

  分析：

  • 策划私底下和程序、UI或者美术等沟通需求，需求变动且QA不知情。
  • 游戏基础模块初版未制作完成且测试通过，策划便将了后续内测时的玩法活动提上了日程，因为玩法活动与基础模块间存在耦合，所以导致在开发玩法活动时影响到基础游戏模块的测试。

  解决思路：QA与策划多沟通达成共识：如果需求有所变动，在通知程序等其他职能时，也应该知会QA；同时在排期的安排上，需要各个职能leader进行开会商讨，每个职能从自己的职能角度出发，考虑研发内容安排在当前版本进度是否能完成、各种风险项、以及开发风险预案等

• 版本质量标准不明确，QA无法自主判断缺陷是否该提成bug

  分析：

  • 在当前版本研发内容确定后，策划未明确当前的验收标准，只给QA一个需求文档、通知QA该功能做完可以开始测试。
    标准不明确，QA只能将所有不合理的地方提成bug，策划再审阅一遍；这样做明显拉低了效率，浪费了两个人的时间。如果标准明确，那么上述的两件事所花费的时间完全能够节省下来。
    正确的应该，例如：需求文档A中写着1-10条需求，策划说我们这一版本先做1-5需求、保证玩法功能没bug、UI美术等效果不缺失、体验先不管，剩余的下一版本我们迭代提需求单再做。同时，分配给UI的需求制作单也要挂上对应负责的QA，在需求制作完毕后，UI应该将设计稿贴出来。这样QA对于界面UI才有一个明确的标准，而不是每次都要去找UI要图。

• 研发流程混乱

  分析：

  • 提需求流程不规范无标准
  • 需求制作完成后，策划通知QAleader后，才开始安排人着手测试，这时QA才刚刚开始介入需求，看需求文档，此时的文档分析意义已经不大了。
  • 项目缺少文档分析流程
  • 需求变动QA不知情
  • 需求评审流程不规范无标准，甚至有点混乱
  • 不同经验的策划需求文档的编写，质量差别过大。

  解决思路：上述说到的这些，其实还不足以表达项目的混乱。最主要的原因点在于项目立项时未进行合理的沟通以及项目规划。最简单的解决方法，QA将项目缺陷以及需要改进处总结完成后，和各职能leader开会进行讨论

• 修复bug时间安排混乱

  分析：
  研发前期处于铺量的状态很正常，但是我们也需要提前将bug的优先级划分标准定下，同时修复bug的时间每周也应该划分出一个集中的时间修复高优先级的bug。而不是说让QA全部提成高优先级，程序看到时在开发新内容的过程中顺便修复。只要游戏还没上线，便会有源源不断的开发需求，如果不合理重流程上安排修复时间，那么bug便会一直在，影响整个项目质量以及进度。

结语

曾经希望提出想法改良项目流程，让大家工作更加有条理效率，但是最后发现上司太过固执己见墨守成规，同时不愿意倾听大家一起项目中遇到的各种问题，所以最后打算自己思考记录总结，作为自己成长的一部分吧~
当然每个项目，每个情况不一样，我们改善流程要从项目本身出发。
才进入行业1年 ，还是一个菜鸟，这篇随笔可能想法太过天真，见笑了