现在大点的公司都有QA岗位，这个岗位主要职责是保障软件高质量交付。本身QA的能力或精力有限，很多时候并不参与软件方案设计，代码review的工作。QA在项目中的保障质量的方法主要依赖监管项目交付进度，审核交付件是否规范，及其制定合适的赏罚制度，避免犯低级错误。因此QA的工作其实是间接的方式影响产品质量。
软件开发是一个不确定性非常大的一个活动，存在着需求变化，架构调整及其人员变化等各种因素，软件开发没有银弹是目前普遍共识。但是公司总有一些人想把软件开发当成流水线，给定时间和人，倒排计划，靠执行僵硬的流程去完成开发，犯着<人月神话>中描述的错误。QA在这个里面应该承担正确引导项目发展的关键角色。
QA应深入了解项目的特点，制定合适的开发流程或者交付质量管控流程。对于确定的无技术风险的项目，可以进行严格的质量流程。对于需求变化大的或者技术风险比较大，更应该采取灵活的敏捷交付流程，而不是瀑布流程，需求变化就各种质量扣分。当时做方舟编译器，非常感谢QA的灵活性和灰度，因为方舟编译器本身需求和技术风险是非常大的，需要不断试错才可以做出来。如果一开始就定死流程，基本项目就死了。
QA需要把握人性，不要让认真干活的兄弟寒心。灰度是QA的学问，在项目不同阶段，灰度可能不一样。不能让干活越多的兄弟，感受干的越多，越被惩罚。所以任何都要具体问题具体看，弄清楚背后的原因，制定合理的措施。如HISI兄弟给的一个例子，一个团队文档各种交付件非常规范和细节非常好，一个团队可能没有那么好。如果不调查，觉得团队1非常厉害，但是团队1搞得是2G技术，已经非常确定成熟，兄弟们本身就活很少，而团队2面临4G-5G需求，存在不确定性，文档也没有那么规范，大部门兄弟还在不断试错过程。不同阶段任务重点是不同的，要具体问题具体分析。
QA是一个要求非常高的岗位，要引导项目正确的价值观，为最后成功做出自己的努力。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
