关于开展 QA 工作的建议
结合我有限的经历，和对 QA 工作的浅显认识，阐述一下我对该项工作开展一些思路和建议，我尚不能提出完整的解决方案，只能针对一些点抛砖引玉，以下看法源于我过去从事不同工作岗位获得的经验汇集而成，生命诚可贵，时间价更高，奈何诸多原因，对每一次经历的岗位可能理解都不深入，因此可能与真理相差十万八千里，如果有明显纰漏的地方，权当我抛出一个论点，供大家讨论。
准备开展 QA 活动：
无论从公司获取某些项目招标资质或是从自身持续发展，开展 QA 工作，以及进行如 CMMI 等认证的活动都是很有必要的，这一点需要得到全员的认同，特别是高层、产品经理、研发经理的认同及支持。基于我个人的经验总结，开展类似工作的阻力基本集中在高层的坚持不够、项目经理的重视程度不够、研发经理的配合度上，其他诸如测试部、售后客服、运维对此的配合程度相对高很多。究其原因在于除了各职能岗位对 QA 工作的认知不同外，更重要在于 QA 从业者本身的能力及素养。
一个好的 QA 能够影响团队，逐步让团队中的成员认同 QA 活动，而不是持续被团队排斥。BUT HOW TO DO？QA 应该是提供解决方案的参谋，而不是简单的第三方监督。我认为，大多数人应该都不喜欢被人监督着做事，也不会喜欢被人指使着做事，我了解到的 QA，很容易或者已经成为了 “事儿妈” 这种角色（这是不正常的现象，应该是我了解的对象还不多，或者没有接触到 QA 活动开展成功的团队）；
如果一开始定位 QA 活动是监督，检查的范畴，稍有不慎，势必导致上文所述的结局，无益于项目进行，可能仅仅有益于出几个漂亮的报告给老板或者投资人看！
QA 活动应该有独立的责任人去负责开展，如果兼职，一旦工作冲突，QA 活动势必会优先级降低，一次降低，次次降低，QA 活动也就流于形式，最后不了了之!
SO：一旦准备开展 QA 相关活动，我建议做以下几件事:
高层对全员明确 QA 活动的开展决心 ---- 提高到战略层
选择一个中长期进行的项目 ---- 短期项目还不够热身
选择一个 “别人乐于” 与他沟通的人，且善于整理琐碎事务，确有坚持不懈的毅力的人负责 QA 活动的组织和推进 ----太强势了不太好，因为 QA 应该是参谋，而不是军长！
初期开展 QA 活动：
一旦确定要做一件事，剩下的就是怎么做了，如果还有 “关键干系人” 质疑开展的合理性，那么先达成一致在继续后面的工作。
一个已经有所沉淀的团队，要引入新的游戏规则，新的玩儿法，必然有人不适应甚至抵触。何况，经验表明，QA 活动的开展初期，还是在给团队增加工作量，更是不受大家待见！
据说在制造业界，ERP 风起云涌的时候，不但没有救活一些公司，甚至差点被玩儿死了，后来专家分析，这些极度不适应的公司之所以没有折腾好，是犯了拿来主义，硬着陆的错误。QA 活动开展个人认为与这相似，如果一开始就上来一套完整的制度方案，方案要么是拿来的，要么是屁股决定脑袋拍出来的，得不到团队的支持不说，很可能会严重干扰到项目原来的进度和节奏。
我建议的方案是从细枝末节做起，逐步渗透，高调的启动，低调的介入。
比如以下几个点（很多工作我们已经在开展了，后面要做的就是例行，习惯！）：
每次关键会议是否有人记录，针对会议决议，在下一次节点会议进行 review 是否履行决议，未决决议是否有专人跟进（只是跟进，不是要他解决）
需求变更、设计变更做一下根因分析，比如：这个字段为什么要设置为 String，为什么不限制长度，为什么要设为主 KEY，…为嘛要更改需求，客户的真实意图是这样吗，他到底是要一匹跑的更快的马，还是更快的到达目的地……；总之，如果行文阐述不清除你的变更理由，说明你还没有想清楚，没想清楚就会随意，随意做出的决策，只能呵呵了！
关键变更是否知会到变更干系人了，为嘛不让他给你复述一遍呢？磨刀不误砍柴工，这个时间绝对不能省！
关键文档按规范更新到指定目的地，行文的时候，相关附件有明确的指向，明确的版本号；文件命名是否明义，他人是否可以见名知意，你自己三个月后能看明白吗？
你写的文档中形容词多吗，你怎么保证你的形容词，别人和你理解的是一样的？
代码注释写了吗，日志打了吗？注释和日志不仅仅是注释记录这个类 这个方法，还有一个作用就是梳理自己的思路，也就是说，你想清楚了吗？
最重要的，有人跟进以上活动是否开展吗？
当然还有很多其他的工作需要做，但是，多了就没有重点了，多了就 “不容易改变” 了，因此需要 QA 关键干系人共同决议几个短期目标，坚持做下去！另外就是 QA 岗位本身的责任人，得坚持，我始终相信一个道理：
你坚持做一件事，坚持到大家都感动的时候，神仙都会来帮你！
QA 活动不是一个人的事，不是 QA 岗位的私事，需要有一个专家团队协助支撑他的工作，在初期开展活动的时候，专家团队可以是砖家团队，亦即不一定是某一个细分领域的专家，但一定是能了解该领域基本术语及基础的人。基于当前实际，专家都在各个团队的核心岗位，忙于处理项目本身的各项事务，一开始就将他们纳入到 QA 支撑活动中意义不大；可以再砖家团队无法拿出预案或者预案未决时，让专家参与决策即可！
SO:开展 QA 活动初期，我的建议如下：
QA 活动干系人确定 3 个月短期目标，各个部门节点的细分目标不超过 6 个
指定专人负责跟进各个目标的达成情况并每周公布
目标需要有导向性，必须与绩效挂钩，并取得高层的认可
组成 “砖” 家团队，负责支持统计 QA 活动的开展情况及评审
后期 QA 活动开展：坚持，在坚持！
最后，提个问题，什么是 QA?,引用最近一部电影中的话，QA 无处不在！我的理解是，QA 是一类活动的总称，一切可以触发软件质量改进的活动，都是 QA 活动的范畴，身居 QA 岗位的人做的就是发掘那些可以触发软件质量改进的活动，并分析活动是否可持续开展，总结并推广活动！
那啥。。你确认你说的是 QA，不是 Tester 么？
写了这么多真心不容易, 感谢对论坛的支持.
说实话 51testing 更喜欢这类的文章.
好像通篇都在介绍高大上的管理理论, 这些理论适合在大公司和传统公司搞管理. 但是很难适应创业公司.
真正的管理是要根据团队的情况去制定适合的方案.
37signal 的那本书里曾经提到, 要招聘在一线工作的人, 招进来的不亲自负责实际工作的纯管理人员会把大量的精力运用在各种可以让他有展现自己地位的规划上, 其结果是管理, 流程繁杂无比. 而且开会也会是这类人的爱好.这会拖累一家公司的发展.
推荐你翻看下这本书. 我也一向不喜欢业界的各种假敏捷,
不过相对于你目前的理论. 我还是觉得你应该看看敏捷类的实践.
当然如果身处传统的公司, 也只有这么做才能保住 QA 的重要性和地位了....
里面提到的一些管理细节其实都是不错的实践. 不过公司衡量 QA 的价值, 不在于流程有多细致.
而是在于是否可以加速产品迭代, 提升产品质量, 降低整体成本. 如果没有具体的测试过程和技术保证, 就很难 hold 住产品和研发
同感，假敏捷感觉基本上就是这么玩的。
我们的专职 QA 的主要工作就是写写 PPT，有问题抓人写文档，写完抓细节，技术他也看不懂，组织知识竞赛啥的。那是相当的轻松啊。
当然也有可能是我理解错了. 这是和群里的朋友讨论的结果
觉得不错, 也分享给楼主..
谢国文-Pactera 2014/12/31 13:45:45
这个是 QA，不是 tester 了，不过创业公司测试都少，更不要说 QA 了
Monkey－alipay 2014/12/31 13:46:25
是啊。＝ ＝
Monkey－alipay 2014/12/31 13:46:29
所以我第一个就在问。。
Monkey－alipay 2014/12/31 13:46:34
怎么会讨论 QA 呢
13:51:57
言笑-Testin 2014/12/31 13:51:57
QA 真是高大上的职位啊
谢国文-Pactera 2014/12/31 13:52:54
我刚毕业 1,2 年的目标～～～
谢国文-Pactera 2014/12/31 13:53:14
一般搞认证的公司会有这样部门，敏捷类的基本不会有了
13:56:44
Sunrise Sunset 2014/12/31 13:56:44
其实文章提到的几个方面还主要是开发设计的范畴，确实不是 tester 的工作，其中主要的类似关键会议记录，执行追踪，需求管理不在敏捷迭代中进行，但是不做这些反而会让客户的需求失控；文档和代码规范书写觉得应该就是开发需要日常工作的下意识做法，否则后续开发维护很难进行，这个跟敏捷不冲突啊？这些都不是测试的工作但是属于 QA
言笑-Testin 2014/12/31 13:57:43
我怎么觉得是属于产品经理的范畴
Sunrise Sunset 2014/12/31 13:58:26
产品经理偏重于交付的成果
Sunrise Sunset 2014/12/31 13:58:38
中间产物反而不是很在意
13:59:27
言笑-Testin 2014/12/31 13:59:27
进度管理和迭代成果的验收, 他们应该关心吧. 还有跟客户的沟通.
Sunrise Sunset 2014/12/31 13:59:47
以前遇到一些敏捷项目因为前续的项目什么文档都没有，代码没有注释，所以接口都是处于猜测状态试错
言笑-Testin 2014/12/31 13:59:53
好像产品经理才是整个过程中最紧盯的人
Sunrise Sunset 2014/12/31 14:00:38
项目进展极其艰难，交付期总是失败
Sunrise Sunset 2014/12/31 14:01:23
虽然客户很理解，但是觉得很多时候我们把规范的东西跟敏捷对立了
14:01:36
Sunrise Sunset 2014/12/31 14:01:36
一时敏捷，一世糊涂
14:05:22
Sunrise Sunset 2014/12/31 14:05:22
长线产品和短期交付的矛盾在敏捷方法中经常处于交锋状态，关键核心部件的设计，用户宽容度很低的产品，敏捷面临的风险极大
14:07:36
言笑-Testin 2014/12/31 14:07:36
我觉得好像也不是敏捷的错吧. 敏捷也不是不写文档.
言笑-Testin 2014/12/31 14:08:02
最近公司请了一个技术牛人, 是 apache 项目的维护者
言笑-Testin 2014/12/31 14:08:23
目前是 remote 工作方式
Sunrise Sunset 2014/12/31 14:08:25
我们很多产品其实都是短消费产品，用户都不知道你的产品究竟要达到的目标，即使有些小毛病也会忽略掉，但是比如关键商务，物流，资财的管理宽容度极低，基本不允许出错，这类软件系统需要更高质量需要更好架构
言笑-Testin 2014/12/31 14:09:13
他们使用的方式是 jira+git 他们对 jira 中的每个 issue 要求很高, 等价于敏捷钟的 backlog 吧.
Sunrise Sunset 2014/12/31 14:09:20
敏捷其实特别适合牛人工作
14:09:56
言笑-Testin 2014/12/31 14:09:56
他们对提交的问题, 要做的事情, 有很强的规范. 还要每个 commit 都要对应到功能.
言笑-Testin 2014/12/31 14:10:09
基本上 issue 列表就已经是功能文档了
Sunrise Sunset 2014/12/31 14:10:29
尤其是技术高超，习惯良好的团队，效率极高，这也是当初为啥那些 17 个人提出敏捷的原因，因为个个都是牛人，每个人都有自己的敏捷方案
Sunrise Sunset 2014/12/31 14:11:46
其实能够写出言简意赅的 story 本身就很不容易，还不引起歧义，我看文章中不太赞同过多形容词，其实也是血泪的教训
14:12:41
Sunrise Sunset 2014/12/31 14:12:41
文章不是高大上的那种，但是能看出来确实是实践中得出的教训
14:15:16
Sunrise Sunset 2014/12/31 14:15:16
敏捷我觉得是个过渡的方法论，需要另外一个东西替代它，兼顾短期交付和长期的架构设计
谢谢大家的回复
不过我想再说明的一点是，我本身也是非常讨厌理论派，任何理论的东东我都努力给出具体怎么做的步骤，具体的交付物,具体的标准。
我写这段东东的初衷给我们的团队，也是想传递一个想法，我们可以不用纠结要不要 QA 这个职位，也不用去想哪些是 QA 做的，哪些是项目经理做的，哪些是测试或者开发做的，共同的目的是改变现状，提高在快速迭代过程中产品的交付质量。
一开始准备招聘一个经验丰富的 QA 从业人员，我直接否定了这种做法，一上来就是一套完整的体系制度文档，就是硬着陆，我更加喜欢根据自己团队目前的结症，每个月改进一点点。
不知为何本文会和敏捷扯上关系？我反复看了我的行文，似乎是我写的 QA 活动几个点在几个月内实现之类的话将大家的思路引导到敏捷上去了，我本意并非如此
我所指的活动改进，是项目进行过程中的不好的习惯，而并非 story。本意旨在形成了良好的习惯了，产品质量自然会一定程度提升
在做质量前，个人觉得先得给质量下个定义，一个适合自己公司的质量定义。你现阶段关注的是什么？要达到什么预期。这个很关键。
质量是为公司服务的，而公司是为了盈利而生的。那么产品的商业价值是不是也应该放到质量的范畴？
既然扯到了商业价值就自然而然的扯到了商机，特别是风生水起的互联网。
那么如何在商机和过程管理以及测试之间去平衡呢？
好吧，这就扯到了各种策略。该抓住什么，该放弃什么。
在市场争夺战中，很多东西是可以先暂时放弃的。
等市场到手后再做也不迟。
扯远了。。。。。。拉回来:
一切不以提高软件质量为目的的活动都是耍流氓！一切有助于提高软件质量的活动都是好过程！
我以前就被一个 QA 找毛病、挑刺，写了几百个案例，结果因为一个极小的手误（无关紧要的字符问题）整个季度评了 C，然后果断受不了跳槽了。80,90 后的员工现在都要工作做的 “爽”，不爽我就不干了，与钱与其他无关。
公司规划了 QA 团队，学习一下。
我的神 多年没有上论坛了 发现 n 年前的思考 以及大家的评论，内心居然有点小感动；
关于敏捷：这么多年过去了，我跳了好几个团队，大多数都是伪敏捷，或者说大敏捷，小瀑布，或者说需求敏捷，研发瀑布；这方面我还需要成长，多涨见识，属实没有见到敏捷玩儿的很好的团队；也许是能力有限，不能加入到更优秀的团队涨姿势。
关于 QA：我回顾了下上文，确实时间久远，也记不清当时的思路了；确实我想表达的不是 tester 要做什么，而是偏向于 质检、SQA、质量运营，这类岗位；不同公司叫法不同；不过大题上，就是做质量文化建设、搞流程规范建设、做过程质量管理、撸质量结果评价、推质量改进方案这类事；
关于质量和效率：这 tm 是个操蛋的话题，真的得分行业、分业务阶段、分阶段目标，当然这个明面上都会说：我都要，但是实际呢，用户增量都没有，产品都不知道会不会被认可，玩命的搞质量？不快速迭代？相反的，一个相对稳定的产品，要寻求突破寻求增量，一堆产品在哪搞需求，但是都没有明显的商业收益，技术团队如果不拿 ROI 去挑战下，也是等被 diss 的节奏；
当然会有人讲，快速迭代和高质量不冲突，我也认可，但这中间有很多变量：比如怎么个快速，比如团队技术能力，团队人员稳定性、需求密度、团队业务熟悉程度；我觉得任何时候不考虑这些点，就说我都要的负责人，绝对是流氓！遇到这种要耍流氓的人，搞质量的就一定要前置，左移动，是那种极度前，极度左的；而且得充分拿过程和商业收益对比说事，倒逼流氓做选择，而不是他想用什么姿势就用什么姿势；否则，就等着背锅，你想说不反抗躺着享受都不可能；
还是回到主题：QA/SQA 随便怎么说吧，搞质量一定是要和团队目标契合的，充分沟通，充分暴露风险，让产研测运一起决策当前的质量目标和投入，才是最优解，自己在那意淫肯定会被人说你务虚；
采集数据 -- 说明现象 -- 分析根因 -- 摆问题 -- 出多套方案 -- 共同决策 这是正确的思路
实际落地的时候，有部门墙、有不同团队的利益冲突、有优先级冲突；怎么把质量团队的活动和项目/产品/公司大目标绑定，是个技术活儿！
再说点不成体系的杂言：
很多时候，希望能有短平快的动作，既能快速拿结果，又能支撑绩效，又能吹牛晋升，脏乱杂的活儿没人干，或者不愿意干，抓大放小；但实际上，支撑系统稳定不出乱子的 80% 工作，就是这些细节，每天改进一点点，谁说站在光里的才算英雄；
希望所有质量工作者能坚持初心，干到 70 岁！你的初心是什么！
欢迎加微交流： xiancrazy