taobaoQA的葵儿之作，任何一个项目都会有总结，善于总结才能抓住事物的本质，否则永远浑浑噩噩的。当然，在不同的职位上，所做出的总结也会不一样，但总有可以借鉴的地方。了解团队中其他人员的问题，结合自己的问题，相信，取精华去糟粕，总可以得到一个相对来说比较适合的方案，给下次开发打下良好基础。
原文如下：
一、项目中如何正确投入测试资源？
五彩石之后，我参与收费线，一度进入了修整期，主要工作是日常。前一阵子有个比较大的项目成立，但是由于人员不够，便决定安排日常与项目兼顾。当时我凭以 往经验认为，在项目前期阶段，我们是可以做到将两者兼顾的。但事实是，那段期间并没有按我的计划进行，由于种种原因，也可能是我的时间管理出了差错，我们 把多数时间投入到了日常，剧减了前期去理解项目需求的时间。而这一决定直接导致了在UC评审时没能很好的明确把控住，致使现阶段我们的测试成员还在为确认 项目中某些功能需求而犯愁。
当这个风险暴露出来后，我曾反思：日常与项目兼顾，以前我可以，为什么现在做不到？是业务复杂度的问题！是时间管理的问题！是团队 合作的问题……原因可能还有很多，而我作为项目的测试负责人，前期没将这些风险完全评估出来。即使有一万个理由，也还是一个不称职的测试负责人。
总结：在项目启动时，最好能将资源完整投入，特别是业务比较复杂的项目。若确实出现资源不足，应该及时且坚决地反馈出来。
二、对UC评审的把控。
对UC质量的把控，本该是开发人员的事。但UC写出来，看得最多的则是测试人员。所以测试人员对UC的质量是最关心的。那么从测试的角 度，什么样的UC才是可以通过评审的呢？我们现在的流程中还没有完全的标准，这就需要测试人员靠前期对需求的理解来把控。要是前期投入时间不够，自己的工 作没做足，在评审时找不出有效的问题。或是由于项目进度，虽然评审出问题，但之后马上进入下个阶段，那么将会导致后期过程中问题多、反复问，此时开发修复 完善的积极性又不高。最终致使测试理解需求准备阶段进展较累。这也是前一个问题带来的直接后果。
总结：虽然我们的流程，对特殊的项目可以适当灵活运用，但无论是什么项目，UC对测试人员的指导参考价值是第一位的。这回的教训再次告诉我，在UC评审阶段一定要把握好这个度，那么前期一定要有足够的时间去做准备。
三、项目中的沟通、协调。
一个项目比较大，投入的开发、测试资源肯定也就增多。这期间，成员中出现了沟通上的问题，也曾为之愤愤过，也曾努力协调过……
总结：在测试团队中收集上来的问题，理应站在测试者的角度考虑，但对这类问题也要学会过滤整理。我们每个人的性 格不一样，看待问题的态度也不同，作为测试负责人，要综合平时对队友的了解，具体对待。项目组是一个整体，我们的目标是一致的。而且从产品线的角度，大家 将是长期合作的伙伴。虽然我们对事不对人，但可以寻找更好的沟通方式，不该因小问题上大和气。
我们的项目业务比较复杂，繁多，所以周期比较长，现在发现了，还可以从某些方面做些弥补措施。但对多数项目来说还是短期的，可能问题发现了要到下个项目中才有机会去弥补。
本来想项目结束后再来好好总结的，不过现在这些教训等到项目结束后，感觉可能就不太一样了，所以想先写出来，以督促自己，也供大家借鉴。