软件开发的众多角色中，唯有QA，是被扭曲的最严重的。我访问过几个QA，他们是这样看待自己的工作的： 

Vicky：“QA必须要像一个开发一样思考，理解业务逻辑和代码实现细节。”

Patrick：“程序员每次都怼我，说一个外部人员怎么可能理解项目的情况。”

Sam：“QA = 测试 + 打杂。”

Cherry：“我刚毕业一年，什么也不懂，每次跟项目组沟通都很心虚。”

……

我非常理解项目团队都不愿在百忙之中，还被人指手画脚。可如果你去潜水，一边穿装备，一边被教练检查，你一定十分乐意。因为，教练的检查，进一步保障了你的安全。QA检查也是一样的道理，不是因为不信任，而是要再次确认，提高“安全系数”。

在我们不否认检查的必要性后，接下来要解决的就是WHO和HOW了。

因此，QA的质量保障工作，是通过直接保证软件开发过程的质量，来间接保障项目的质量：

 - 确保软件开发过程和过程中的产出，与定义的标准、规程的要求是完全一致的

 - 确保能及时发现过程、产品，甚至是标准和规程中的不足，并提醒管理者及时改进

千万不要被QA的名字所迷惑。软件的生产者，才是唯一能保证质量的人。QA的工作是监督那些对质量负责的人，提醒他们注意实际情况与标准之间的偏差，在产品交付之前解决质量问题。否则，QA就会变成成本高昂的无用功。

你可能要反驳我了：实施Scrum敏捷的时候，压根不需要QA！那么请问，在Scrum中，谁来保证团队按照流程来执行？回答当然是敏捷教练（CSM）。既然敏捷教练在负责团队按照流程执行，那么CSM就是Scrum里的QA！

如何才能让QA发挥作用，突破高质量软件开发过程中的障碍呢？胜任QA一职，需要具备哪些主要能力呢？

 - 对项目计划和从属计划的完整性进行评审

 - 参与需求、设计和代码的审计

 - 对所有测试结果进行评审

 - 定时审查配置管理的执行情况，以确定是否符合标准

 - 参与项目的阶段评审，为何没有达到合理的标准与规程要求，需要记录不符合项

 - 定期审核过程、标准与规程是否满足项目的需求

 - ……

从广度上来说，上述列举覆盖了软件开发的整个周期。从深度上来说，QA可能是一个人，但做好QA需要一群人，尤其是高层管理者。如果高层管理者有决心，在项目组没有解决QA问题之前，不允许交付的话，那么QA就可以帮助管理者不断改进产品质量，获得更高的效率和客户满意度。

上图是比较理想的组织架构。之所以理想，是在于以下三个方面：

1. 质量与研发平起平坐。项目执行很重要，但项目的质量保障和质量改进也同样重要。

2. 独立于项目组的质量部，是QA工作客观性的保障。

3. 上面两点衍生出了第三点，质量与研发的平衡关系，是QA和PM需要共同努力的方向。QA要改进审计工作，让项目团队不反感；且可从中获益。PM要让项目团队明白质量和改进的意义，处理好QA提交的问题与不符合项。

说完了QA的What、Who、How后，我们来重新看一下开篇的例子。

B公司的做法显然是极不成熟的，但恐怕是很多公司发展过程中不可避免的。这种情况，需要意识上的觉醒，认识到过程决定质量后，才会慢慢改善。

那A公司呢？你可能会觉得A公司的QA太重了。从质量的角度出发，这一点我倒不觉得是问题。真正的问题是A公司的QA直接参与PM的考核，打破了与项目组之间应有的平衡关系。这会导致项目组为了QA而QA，把改进变成了负担。