应版主的要求。单开一个帖，说说我的QA日常工作。一来给QA工作正正名份，二来和大家交流切磋。

引用:

原帖由 henrybenben 于 2008-5-10 22:40 发表
很同意楼上的看法。
不知道你是否可以再展开来谈一谈你在日常工作中的一些事情。
期待中......

下面分三部分：
1。说说我现在的日常工作
2。说说我所认识的QA工作
3。说说我对自己及QA的发展的认识

另外，表达一下我对震区人民的哀思。祝他们尽快恢复正常的生活。

[ 本帖最后由 callmechen 于 2008-5-14 17:51 编辑 ]

1。首先说说我所在的公司
它是中国最大的应用软件开发和集成商之一。我公司是以产品线为业务框架的。我属于项目管理部，负责某产品线的CM和QA工作（这里之后会展开说明）。公司已经过了ISO9000和CMMI3级。

2。我的日常工作
我所协助的产品线是以项目为单位的矩阵式结构。只要项目经理提出QA申请，我们项目管理部就会派出一个QA对其项目进行跟踪。
项目一般是在项目计划撰写的时候才确定QA。所以之前的商务、需求等阶段的内容我不去关心。从项目计划开始，只要项目经理选择了需要QA，那么我就要按照项目计划和公司级的相关流程，对此项目进行跟踪。

日常工作无法一一列举。我就挑几个重要的说说：
首先，会议是最重要的：为了控制和掌握项目的会议，会议平台要由QA来预定。每次会议都要有会议纪要，我是QA不是秘书，我要记的东西只是方向性和关键性的内容，技术层次的我不关心。会后把纪要整理并发布，还要抄送给高层。最后记录在项目跟踪记录中。此类会议严格按照项目计划执行，少的时候每月一次，安装的时候能达到每周两三次，每次20多个省市参加电话会议。。。

然后是计划跟踪：在项目计划发布之后，会有相关的提交计划（测试、安装、验收）。每到一个提交日期的前三天，我就要进行提醒、检查、催促。至于他们提交的东西是好是坏，我是QA不是QC，那是测试、工程、客户来检验的。被退回--OK，我接着跟踪；被通过--OK，我给你记上。到了截止日期，我不管你是谁，直接通报并且抄送高层。还要记录在案。不过在这里我也做CM的工作，配置库由我管理，有些时候还要细致地检查一下提交程序的质量。还要分配权限、解决问题等等。

最后就是项目审计了。每个项目关闭，我要整理QA跟踪记录；每个年底，我要整理QA年度报告。我是QA不是文员。我要按照公司级的规范来检查手上的项目，符合与不符合都要识别并记录，该获取的数据还要自己整理，最后发布。

我现在还是初级QA，同时身兼CM（发展方向犹豫中），所以日常工作中真正体现QA价值的地方还不多。但至少可以说明，我是QA，不是秘书、不是QC、不是文员。

[ 本帖最后由 callmechen 于 2008-5-14 17:50 编辑 ]

下面说说我所认识的QA工作：

QA，虽然是质量保证，但一定注意，它是“保证”而不是“检查”。尤其是在大家所在的IT行业，产品质量是由专门的部门去检查和测试的。其实我们有必要追溯一下QA这个职位是从哪里来的。QA应该是随着CMM才被中国广大IT企业所认识的，在CMM里它叫QA，在ISO里它就是内审员，虽然有些不同，但基本差不多。换句话说，QA是一个保证流程、通过保证流程来保证产品质量的岗位。清楚了这一点，很多问题，自然就有答案了。

比较成熟的QA，应该是在企业中的独立部门中，既不属于测试，也不属于开发，他应该站在公司或产品线的角度去看待项目。比较理想的QA，我个人认为就是理论派的项目经理。我所在的公司，项目经理都是实战型的，虽然也受过相关管理类培训，但在企业以项目为主导的氛围中，始终无法摆脱自己“技术负责人”的角色，再加上公司的体制原因，成本、人资、合同、售后都不需要项目经理去考虑，导致他们一直都对QA有严重的依赖性。原来的QA，基本就是像某些朋友所说，成了项目经理的秘书，写这个文件、记那个会议、添这个报表，甚至去帮开发或测试干活……

有的同事说，QA最好从开发干起，这样能更贴近开发的思路，从开发的角度去考虑。其实我觉得，QA最好是从管理理论干起，用自己“倔强”、“固执”的管理理论和严格的公司规程去和现实发生碰撞。在碰撞中，矛盾双方各自提升-项目更加正规科学，QA的经验得到增长。我接触的很多QA是从开发转过来的，他们在很多须发挥“坚持”作用时，立场就不自主地站在了开发那一边：需求变更还没等评审，自己就帮开发说话“这个确实得变，他们开发目前做不了。。”。他们就没从QA的角度去想想此此变更对整个项目的影响和产生的风险；他们就没想象，这种在评审前中立方就已经倾斜了的评审，还有意义吗？

上次公司请一个老外来讲CMMI4的时候，说我公司目前也就是3.5的水平，QA还是没有清楚认识自己的职责，做了很多不该做的事情（主要是他不了解我公司项目经理的实际情况）。当时举了个例子，说我们的QA参与评审会过于投入，有些评审会完全可以不去参加。无论是需求、开发、安装、初验、终验，只要能按照规程，保证相关干系人参加会议，最后交上一份大家都签字的会议纪要，根本不用QA去参加会议。仔细想想也是，客户总不会虎弄自己乱签字吧、售后经理也不会对开发搞出的隐患视而不见吧、测试更不会隐瞒测试出的问题吧。大家都把自己那环做好了，产品质量有什么不好控制的呢？还有，客户的时间总不能瞎耽误吧、高层的时间总不能瞎耽误吧，那会议质量自然就上去了呀，为什么还要QA去控制呢？看似，好像是我们都没有掌握科学的管理方法，其实根本上，是我们还没有深刻理解QA的工作职责。。

接着上一段，ISO和CMMI当中并没有为我们提供一个标准的流程，它们的本质是要求我们自己制定流程，并去执行它。所以，QA的工作不仅仅是执行公司的规程，更关键的还是要去修订它！这才是高级QA的本职工作。

说的比较乱。。边开会边写。有不清楚的地方，还请探讨。

[ 本帖最后由 callmechen 于 2008-5-16 15:16 编辑 ]

最后，说说我所掌握的QA的发展。

其实我刚才在另一个帖的回复中已经说了：
初级QA是领导的眼线，只管观察、总结、反馈、记录。事情交给相关高层去解决。
中级QA是领导的帮手，不但要有初级QA的职责，还要协助高层和项目组分析数据、提供决策支持、提出风险及控制风险的办法。说的通俗一点，就是介于管理层与技术层中间的“翻译”和“参谋”。
高级QA是领导，指导其它QA工作，解决其它QA的难题，牵头制定QA策略和相关公司规程。
当然，QA也可以转行，做培训、项目经理、行政……都有可能。

我的经历大概是这样的：初级QA做了近一年，跟了6个项目（有大有小）；中级QA做了两年多，其间因为公司某高层发现QA和CM结合在一起比较“科学”我又兼职产品线的CM；现在刚刚接触高级QA的工作。部门领导找我谈话时，就为了指了三条路：1去人资发展部做培训，2去做行政领导（非业务部门），3继续学习CM，接他的班。。。

我本人倒是觉得，如果是专职QA的话，大致就两种发展方向：如果懂技术，那么就尝试着去做项目经理（一定要找一个氛围好些的东家，否则累死都没人看得见）；如果不懂技术，那么就发挥自己的理论与经验优势，继续做QA相关工作（以后也有可能走上咨询、培训的道路）。当然，最好的发展是，老板看你真是把好手，分你百分之三的股份。。哈哈~~

总之，QA在中国目前来讲，算是刚刚被重视，前途尚不明朗（国情不同），但一定是光明的。大家多多交流，多多学习，自然就会成为优秀的QA。

[ 本帖最后由 callmechen 于 2008-5-16 15:53 编辑 ]

请楼主有时间可以将第2点和第3点写得更详细一些。

其实你在写的过程以前做的事情会回顾一遍，有很多新的思路也会出现。这是我的一点点感受，拿来和大家分享 ：）

说的确实不错，可是我现在担任的QA好像就是什么事情都做
我们公司的老大的把这个角色的定位就没有认识好
领导一定要QA紧跟着项目才是做好QA的首要前提，你认为是这样的吗？

外加一条，逛逛51test，看看最新技术

写的很好，符合很多公司的实际情况。改天我找我们公司的QA也写一个看看。哈
我回答一下llchen的问题，答案是肯定的。QA如果不紧跟项目，那如何了解项目的情况呢，如何能发现项目的问题呢？QA不是光靠看看CM库里面的那些文档就能发现问题的，不是不可以，但远远不足够。

打个不太恰当的比喻，QA与项目的紧密程度就像已婚男人与情人的关系。

跟的太紧密了，就结合到一起了，起不到旁观者清的作用；跟的远了，就相互不了解了，会渐行渐远。

所以QA深入项目的程度也是一门学问。

想了解一下，你们公司QA和项目的数量比例？同一时间，一个QA一般负责多少个项目呢？