本人做过1次QA和一次伪QA。作为质量保证这个职位来做，其实大部分时间应该是偏向管理职能的。但是现在有人问我QA需要做什么，我是不会把我学理论那套东西去跟他解析什么是QA，我也不会这么说。下面我会这样总结QA的工作。

　　大部分的时候，QA肯定是得罪人的工作。你对QC好，那么你会某种程度上得罪你的领导。但是你站在领导方，你会疏远你和QC的距离。虽然是偏激，但是其实很多人心里的真实想法是这样，作为一个职业素养好的人基本不会把这些东西放在表面去呈现。所以QA其实最艰难的地方在于你偏重于进度，还是偏重于软件测试人员。当然QA是越有软件测试经验的人做越好，但是这种情况很少，基本有经验的人都可能成为了PM级别的人了。

　　部分的QA其实没有做过技术的工作，其实在现实项目中，你碰到不会看代码甚至没做过软件测试的人其实不少，这类的QA是把职位当成了管理来做，他会积累管理的经验，会积累很多项目的经验。对于项目进度来说，其实是好事情，但是对于QC来说，你会得到很多不合理的需求和加班压力。因为这个背景所在，QA会对自己的理论和存在感很强，所以工作会超前，而且有时候会放弃QC的利益，对项目来说，我们看到了进度达到效果，但是面临的是很多不和谐且一些技术人才的流动。

　　作为有技术经历的QA来说，我们很多的时候会知道需求和设计合不合理，例如我身为QA的时候，往往也会不自觉的做了很多QC的工作。我曾经因为一直帮一个组员干活，而给上头“教导”过。对于我们这种QA来说，QC之间的关系不会差到哪里去，但是因为我们对需求和进度的设计往往说不，对其提出了不合理性，给出了各种原理和证据。对项目的健康和对QC的工作安排是好事情，但是对与项目进度来说不一定是好事。不是每个项目都会有时间去做培训，或者投入大量现阶段不一定有回报的技术活。

　　我碰过最好的QA是，本身他也参与QC的工作，但是他的参与范围尽量不和别人QC有交集，他了解项目的需求和进度，但是他会把进度的压力“亲切”地表达给各位QC，不是通过命令或者指责的方式来推动进度。因为他和别的QC工作没交集，这时候每个人有每个人的责任制，这时候的加班其实就是按照每个QC自己去衡量了（前提QC负责）。

　　总结下以上的QA难点：监控软件测试进度，安排QC的工作和监督质量，整理和设计自己职能内的文档，是否需要投入QC的工作。

　　所以，作为一个QA，首先最好有软件测试的经验，还有对业务也要持续的了解；在管理方面，要尽量做到承上启下的工作，不能过于偏袒哪一方，要实时的参与每个文档（测试计划，方案等）的设计，即使这个不是你范围额工作。

　　最后，假设我再一次担当QA职位的话，我还是会把需求和很多技术原理都罗列出来，尽可能的把里面不合理和存在的问题给上头反应，让上头来判断是否需要改变这个测试生命周期的一些活动；自己会继续参与QC的工作，尽量做一些能直面到业务和出现不合理的需求（这个也要看个人能力的情况）；让QC自身设计工作计划，有延后就加班。

　　QA是一个会被忽视的职位，不同风格的人做出的职能也会不同，个人认为定义一个QA是天使还是魔鬼，和定义一个好还是坏的QA是很难的，但如果认真抓住做QA的机会，你是成长很多。

版权声明：本文出自 acbennn 的51Testing软件测试博客：http://www.51testing.com/?299791

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。