我对QA工作的一点认识

按照CMMI的框架，QA的职责有二：依据一定的标准对过程进行评价；依据一定的标准对工作产品进行评价。貌似从这两点，让人感觉QA就是在对项目组品头论足，挑毛病，不断的给项目组制造麻烦。有一些问题还会直接报告给高层领导，在领导面前“打小报告”。QA还强迫项目组按照组织的过程做很多开发以外的事情，写很多文档。可能的确存在这样的情况，也有很多研发人员有这样的感觉，我自己也曾经有过这样的感觉。
看了一些书，查了一些资料，慢慢的了解到，质量保证是缺陷预防的一种手段，只有保证开发过程正确的情况下，才能更好的发现缺陷，从而保证产品的质量。QA是项目组的老师、警察和医生。QA首先要对公司的规程、规范了解和熟悉，具有一定的学习和沟通能力，只有自己弄懂了才能培训和项目组成员。在项目组成立之初，就介入项目组，指导和协助项目经理进行过程裁剪，项目估算。在后来的研发过程中，指导每个过程的执行。警察的角色听上去有点严肃的感觉，就是依据公司的规范和标准流程结合项目组的情况进行公平公正的评价。QA还担当了医生的角色，当项目组遇到困难或出现问题时，QA会协助项目组分析问题发生的原因并找到合理的解决办法。所以，QA并不是如前面所说的，QA是项目组很好的合作伙伴和朋友。

举一个QA起作用的例子：有次QA评价项目的设计文档，发现有些内容不够全面和具体，经过QA和项目经理及责任人的沟通，最后决定进一步完善，不然后来的编码工作会受到影响。半个月后，其中的一名程序员张要调走，李来接手，此时张感慨，多亏设计文档完整细致，真有交接才发现节省了不少时间。

我认为真正的QA工作很具有挑战性，要有足够的开发经验，管理经验和项目管理知识。有公平公正的素质和较强的沟通能力。有不断学习、提高自我的精神。要学会换位思考，从项目经理的角度想想项目怎样才能做得更好，项目组应该如何去计划，哪些方面应该重点关注或容易出现问题，与项目经理沟通想法，认真听取项目经理意见，对于问题及时指出，避免项目组走弯路。

另外，QA要按照合理的报告机制来解决问题，否则可能引起很多矛盾。在评价过程或工作产品完成时，不论是否通过，QA都要向相关责任人报告评价结果。有不易理解或有分歧的地方，QA有义务进行解释和沟通，证明QA评价有错误或遗漏的，应修改评价，并重新发送给相关人员。在项目组内不能解决的问题，需要跟项目经理沟通后逐级上报给高层，直到问题解决。发现问题不是目的，重要的是跟踪并验证问题的解决。

对QA工作的度量主要从几个方面展开：投入的工作量占项目总工作量的比例，一般控制在5%以内，如果太多，则考虑项目组对过程理解有问题。QA发现的不符合问题的数量，过程稳定后，QA发现的不符合问题数，应该等于项目组以人月数计算的工作量，比如项目组的工作量是80——100人月，则QA应该发现80——100个问题。对公司的有关过程和标准提出改进建议数量。

总结完上面的对QA了解的内容之后，我清楚的认识到，为什么说质量保证是缺陷预防的手段，QA的确是在为项目开发保驾护航，不再认为是督促研发人员写文档，迫使项目组执行标准过程，为项目组增加无谓的负担。