说点个人对QA的认识和体会

ddqhf

QA，大家都知道，是质量保证人员。主要负责监督项目运行过程中的流程，并且帮助项目发现问题甚至解决问题。我们要做的是规范项目操作，让项目乃至整个公司可持续地发展下去。为此，我总结了以下几点：

1. QA一定要做到自己说话就是权威，不能随意更改。丁是丁，卯是卯。正式场合切记避免“也许”、“可能”等模糊的字眼出现，我们要向其他人传递的就是一种很明确的制度或者说是责任。同样，这就要求QA要对自己的东西烂熟于心。
2. QA说话算话。最起码的做人的准则，QA这里尤其要强调，这是我们让别人信服的首要准则。
3. QA要具有行业基本的知识。起码编码你要会一点，能看懂。设计各种图形你也知道，需求的撰写你也略知一二，测试的基本方法和规则也能说得清楚，这样你才能有足够的资本和他人交流。
4. QA对项目管理所涉及的领域或者方法要有较好的认识。比如风险管理如何操作、怎样识别风险、怎样进行正规的决策分析、决策树怎么使用、头脑风暴法怎么操作、评审的都有哪些类型、分别怎么操作等等。但凡流程里面涉及的，我们都要能在别人需要的时候很快的给出答复。
5. QA需要非常明确项目里面的角色定义。这里尤其强调一下有关“客户”的定义，很多人可能觉得，客户，就是给我们项目做的人。诚然，给我们项目做的，肯定是我们的客户，但是客户却不仅限于此。给个很简单的定义，我们的工作对谁负责，那么谁就是我们的客户。而QA就是需要明确客户是谁，尤其要注意帮助项目经理识别项目组的客户。明确客户，明确客户职责，明确项目组应该怎样与客户沟通，诸多问题，是影响项目变更多少的非常关键的因素。
6. 记住，流程是死的，人是活的，不是什么都得完全按照流程走，这就好比“尽信书不如无书”。可能有人会问我，这样说不是就违背了我们的初衷了吗？我想说的是，没有。请注意是完全按照流程走。其实只要是我们的流程体系建立的较好，那么我们的项目运行肯定都始终是在流程控制范围内的，但是我们却可以不用完全按照流程走。因为中间我们可能会省略一些东西，并且根据客户的要求，我们甚至可以省略某个阶段，比如我们不做测试、不做需求等等。
7. 记住，QA要的是记录，而不是文档，文档只是展现记录的一种方式。流程的定义里面，也要尽可能的避免我们必须需要文档等类似的字眼。因为我们的职责之一就是要确保项目乃至整个组织级的可持续发展，所以记录尤为重要，凡是涉及到项目或者组织可持续发展的记录，我们都需要做要求，这也就是CMMI的来源。所以流程里面，我们可以定义某些文档模板，但是都是供大家参考的，最终结果是项目组只要保有实际且有效的记录，我们就可以认可。
8. 做事不卑不亢。
9. 融入项目组，站在项目组的角度来思考。这并不是让大家排除QA的独立性，QA的独立性肯定是必不可少的。我这里的意思，只是希望大家在角色独立的同时，可以换个角度来思考问题，根据项目实际情况，体谅项目组的难处，查找项目组的弱点，帮助项目组做到真正的提升。
10. 努力做好培训。这里的培训除了简单的流程以外，还需要关注其它诸如流程所涉及的方法等领域。这是培养你权威的很好的一个途径。
11. 努力追求公平的最大化。这主要是当QA在协调项目组内部一些问题以及做审计的时候。这里说下我的情况，由于我们暂时是测试人员归属项目经理，但是项目经理又对测试人员不具有绝对的管辖权。测试人员为了争取他自己的利益，则会经常找到我来帮忙协调，这时候我需要做的就是充分冷静的思考、公平的对待。最终才能得到一个比较有效的结果。

今天心血来潮，没有丝毫准备的写了这么些。先就这样，等到有想法了在继续。言辞仓促，有不对的地方还请大家指正，也欢迎大家一起讨论！呵呵

[ 本帖最后由 ddqhf 于 2010-1-13 15:04 编辑 ]

ddqhf

原帖由 jimmyseraph 于 2010-1-13 16:46 发表
写的不错。
如果做到这些应该就是一个很好的项目QA。
如果你已经做到这些了，我建议你可以向全流程扩展视角。
公司的业务流是什么样的？从市场获取信息形成需求，到研发实现需求，测试验证，到最终交付用户以及售 ...

呵呵，我都做到了的我才敢说哈。你说的扩展到其他部门我做了，不过所谓的客户端到端，这个我还确实没扩展到这种高度。这大概也跟我所涉及的公司业务范围有关吧。

[ 本帖最后由 ddqhf 于 2010-1-13 20:13 编辑 ]

alice_xg

写的不错

liaoxj

学习中！

chengning

ddqhf

ls在刷屏？

francais

呵呵

linliusjz

学习，学习了！

Lyroht

mark

zhangyd

心声 真切

chengxq

说的都不错，而且都有道理，但是真正的能够做到的又有多少，我想问一下楼主，在你们公司度量人员由谁来担当，其次QA需要对度量数据給出质量分析吗？
我只是最近在想QA和度量分析结合起来，才能更得到大家的认可

ddqhf

原帖由 chengxq 于 2010-1-22 15:54 发表
说的都不错，而且都有道理，但是真正的能够做到的又有多少，我想问一下楼主，在你们公司度量人员由谁来担当，其次QA需要对度量数据給出质量分析吗？
我只是最近在想QA和度量分析结合起来，才能更得到大家的认可

对于你说的这个“能做到的又有多少”，我想说这个原因大多在我们QA本身。我想我说的里面还没有涉及多少有关组织结构的问题。
你的问题，我基本上赞同jimmyseraph的回答。
度量人员其实也要分项目级和组织级，在我们公司，项目级的度量人员是由项目经理指定人员来担当的，他的职责主要就是收集数据，而其实项目组对度量数据的分析，主要是由项目经理来完成，这样项目经理才能比较有效的掌握项目情况。而你说的QA对度量数据给出质量分析，这也是肯定的，这是QA从自身的观点结合项目度量数据给出的项目情况分析，高层通过项目经理和QA两者对项目的分析情况的掌握，进而掌握项目的总体情况，同时项目经理也可以借鉴QA的分析，对项目情况有更全面的把握。

个人认为，QA和度量分析结合起来完全没有矛盾，而且很有利于QA的提高和价值的体现。当然，QA做度量分析还需要特别注意自我提升与检讨，因为度量分析立面的数据也有与QA自身相关的，这里就需要QA的客观性更强一些。

另外还有一种度量分析是组织级的，这种度量的目的大概有以下几个：
1. 为以后的项目提供基线化的参考数据，作为组织标准
2. 分析组织的运转情况，让公司对自身情况有着比较充分和良好的认识，帮助组织进行可持续发展
3. 分析各项目的强项弱项，从组织级层面帮助项目自我提高

ddqhf

原帖由 chengxq 于 2010-1-22 15:54 发表
说的都不错，而且都有道理，但是真正的能够做到的又有多少，我想问一下楼主，在你们公司度量人员由谁来担当，其次QA需要对度量数据給出质量分析吗？
我只是最近在想QA和度量分析结合起来，才能更得到大家的认可

话说，好久都没看到你了，呵呵！

bingyi8589

ding

holymonkey

呵呵，，，，，
写得不错，百尺竿头，更进一步。

chengxq

前一段时间公司在搞CMMI5，没有时间上网，现在静下来，考虑QA在公司基本上不被认可，且QA目前实际状况也是查写文档类的偏离
如何提高QA的认可度，我在想，是否将QA管理知识与度量分析结合起来，提高大家对QA认同感，而不是目前QA只是在做文档，当然我
说的度量是项目的度量，而非组织级的，转开发，说真的，前途比较看好，特别是有了管理经验

[ 本帖最后由 chengxq 于 2010-1-28 17:31 编辑 ]

ddqhf

原帖由 jimmyseraph 于 2010-1-29 08:51 发表

同意你的这个想法，很明显你们公司的QA才刚刚起步，做的工作很边缘，作用很有限，以度量为基础用数据说话是提高QA力量的一个好方法，在这个起步过程中一定要多汇报，特别是向中高层汇报，多利用PONC理论。

呵呵，是的，本来就应该结合起来才能更好的体现价值。
前不久面试了深圳一家公司，结果面试官认为我又做QA（项目监控），又做MA，又做audit，还做EPG，却没有一段时间专职做QA的，而认为我QA的经验不足，把我pass了，我当时真觉得好笑。哎~~~~这年头

myfreecall

感悟很深

kekebaobao

请问你们公司QA体系用什么？

ddqhf

原帖由 kekebaobao 于 2010-4-28 09:18 发表
请问你们公司QA体系用什么？

主要还是用CMMI，参照部分ISO9k，会有少量Agile思想