本人做过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的机会,你是成长很多
