QA如何体现自己的价值？QA，从1.0到4.0

以下文章转自蒲公英QA如何体现自己的价值

经常看见大家说QA工作没有价值。个人觉得QA工作不仅不是没有价值，而且价值很高，只是有些人没有认识到QA的价值。

先给大家讲扁鹊三兄弟治病的故事。根据典记，魏文王曾求教于名医扁鹊：“你们家兄弟三人，都精于医术，谁是医术最好的呢？”

扁鹊：“大哥最好，二哥差些，我是三人中最差的一个。”

魏王不解地说：“请你介绍的详细些。”

扁鹊解释说：“大哥治病，是在病情发作之前，那时候病人自己还不觉得有病，但大哥就下药铲除了病根，使他的医术难以被人认可，所以没有名气，只是在我们家中被推崇备至。我的二哥治病，是在病初起之时，症状尚不十分明显，病人也没有觉得痛苦，二哥就能药到病除，使乡里人都认为二哥只是治小病很灵。我治病，都是在病情十分严重之时，病人痛苦万分，病人家属心急如焚。此时，他们看到我在经脉上穿刺，用针放血，或在患处敷以毒药以毒攻毒，或动大手术直指病灶，使重病人病情得到缓解或很快治愈，所以我名闻天下。”魏王大悟。

工作中，只有在企业遇到重大的质量问题时才会外聘一位QA（扁鹊）。这位QA采取雷霆手段将公司的质量问题解决，这时公司同事才能看到QA的价值。事实上，企业遇到重大质量问题的概率是非常低的。一般企业都是经常出现一些小的质量问题，这时公司的QA（二哥）就能组织团队将问题解决。这时公司看到QA有一点价值，那就是能组织团队将问题解决。很少公司的QA（大哥），利用自己知识建设公司质量文化，将很多同类企业和本企业要发生的质量问题通过预防措施早日解决了。这样的企业，公司同事一般会看不到QA的价值。企业质量文化建设好的企业，最不容易体现QA的价值；企业质量文化建设不好的企业，最容易体现QA的价值。

一般来说，企业质量文化建设好的企业和企业质量文化建设不好的企业之和占企业总数的少部分，而介于两者之间的企业占大部分。那么，大部分企业的QA如何体现自己的价值呢？我建议做好这几点：

第一、对于每个已出现的质量问题一定做好纠正和纠正措施。如果可能的话，并做好预防措施。

第二、利用好统计工作，做好质量成本分析，将质量问题转化为财务数据，好引起管理层重视并获得管理层的支持。

第三，做好持续改善工作，将公司质量问题逐步消灭掉。

第四、做好培训，并积极建设公司质量文化。

迄今为止，敏捷开发方法在各个公司都有了长足的发展，曾经的测试人员慢慢的在向QA职能过渡，但依然很多人不了解QA和测试的区别是什么。

敏捷实践不断地演化过程，使项目中各个角色不断弱化，同时，对每个成员的要求也越来越高。“全功能团队”的提出，不单单是对开发的要求，对QA来说，想要在快速变革中具备竞争力，就现在所具备的技能来说，还是远远不够的。

1

简单聊聊我所经历的“QA发展史”




（图片来自ThoughtWorks UX设计师高媛媛）

QA 1.0 —— 机械化流水线作业

在我实习的那年，软件领域还很少提及QA，伴随着瀑布模型的兴起、软件工程规模的不断扩大以及市场对软件质量要求的提高，催生出了“测试工程师”这样一个角色。那时他们的职能很单一，每天的工作就是在各种测试环境中按照详细设计的文档，编写测试用例，并逐条测试，检查功能完整性，发现软件中可能出现的功能缺陷，并进行追踪。

这个时期是软件测试的原始时期，对测试人员的技能要求不高，只要对文档理解透彻，做事细心，是很容易胜任的。此时的产出和交付物可度量，虽然如此，测试工程师只是执行者，能力和价值都无法最大化，却被每天重复的工作所累。

QA 2.0 —— 过程化带来不同的工作内容和价值体现

我毕业的时候，开始接触敏捷方法，团队规模从百人变成了仅有十人左右，信息平等取代了逐级传递，分散的信息源（ 客户的每一封邮件和每一句对话都可能是我们将要做的功能 ）取代了几十甚至百页的文档，测试不再仅是提出软件缺陷和编写、执行测试用例，而是成为了团队的数据库和字典。

当用户提出一个功能的时候，测试人员可以快速的进行需求分析，回顾并确定是否与此前的功能有冲突。当开发人员对某一块业务不了解的时候，测试人员也可以组织会议进行阐明。由于对业务和客户的深入了解，测试人员可以为客户提出建设性意见和功能，有时也会是做出决策的人。

高效、频繁的沟通，大大提升了QA的软技能。此时的测试人员已经过程化，对软件质量的理解，从“发现缺陷”提升到“对软件开发过程的质量控制和风险预估”，我们定义这样的测试工程师为QA。

QA 3.0 —— 自动化技能提高生产力

随着工程实践的日益成熟，QA的角色和工作日益复杂，这使得他们在大量重复、繁杂的工作与更有意义的角色之间频繁切换，这对软件质量也产生了一定影响。

QA从开始的手工测试、探索性测试等手段，逐渐发展成为可以利用工具和程序对测试进行快速的回归，对软件性能进行有效监控，无论是前端还是后端、web应用还是移动平台。这使得自己从繁杂的重复性工作中解脱出来，去做更有意义的事情。他们通过项目的积累以及团队成员的帮助，对测试技术有了一定的认识。

QA 4.0 —— 角色向多技能、服务化转型

记得几年前，前公司领导对我说，“不管开发换了什么技术栈，你做的自动化框架都可以继续使用，对你来说没有任何影响。”当时我也赞同，认为框架已经足够好，可以适用于任何场景和业务。

从某个角度来说确实是这样， 测试相对于开发技术的指数级发展，平稳的太多。不论是在互联网还是移动互联网时代，缓慢的发展速度给了我们一种太平盛世的错觉，似乎我们掌握的技术足够坐吃几年。

来到ThoughtWorks之后，我发现了类似的事情，不论是在交付还是咨询的过程中，会有意无意中推一些我们认为的最佳实践，当遭到客户质疑和challenge的时候，我们似乎很沮丧。

在北京出差的日子，有幸做了一次咨询，虽然只有几天，让我学到一件事，我们认为的最佳实践和方法，并不完全适应于所有场合，尤其是在我们这样的咨询公司，对客户实施怎样的方案，取决于客户的领域、产品/项目特性、用户群、技术水平、政治文化、技术栈以及目标和期望等等。

如果对于“最佳实践”过于坚持，也会影响客户关系和咨询效果。之后咨询同事讲的几个故事也似乎让我认识到，虽然我们对现在的工作和技能足够的熟练，但依然不够。

2

我们似乎还需要具备以下的能力：

1.尝试用不同的方法写“茴”

经验丰富的QA对于测试技术中的关键点都烂熟于心， 除了我们正在使用的方案和技术，尝试用不同的语言、框架去实现关键点和难点。

这样的好处在于，我们可以通过深入的学习和使用，对流行方法、过程和框架进行比较，了解各自的优势和劣势，不但可以增强自身的技能，当面对不同客户的时候，也可以给出客观的分析，为客户提供精准服务，同时如果可以对客户现有的技术和方案、流程和方法提供有价值的意见，也可以提高在客户现场的生存率，轻松俘获客户。

2.If you cannot test it, dev it.

软件过程中，QA可以在需求分析和定义阶段介入，为项目提供不可估量的价值，但另一方面，QA技能实践（此处指Tech）是一个相对受限的领域，我们很难绕过未实现的代码和工程去做更多的事情。

你可能会说，“没有做过mobile的项目，如何去学习移动端的测试技能？”如果恰好你对行业的发展具有前瞻性和敏感度，例如你可能认为IoT和VR是一个趋势，你却没有机会去这样的项目中做QA。

那么我们是不是可以像开发一样，提升自己的学习能力和适应力，保持对技术的敏感度和热忱，了解不同技术领域，对该领域的开发、测试、构建和集成部署都有一定的了解？所以，如果你想比其他人走的快那么一点，go dev!

3.真正的全功能

QA的领域虽然相对受限，但幸运的是角色相对不受限。在日常的开发过程和项目积累过程中，不但能对业务有深刻的理解、对用户行为有独到的见解，而且对技术也有一定的认识。

在需求分析过程中，QA总是可以从技术和业务结合的角度扮演好一个BA的角色，成为一个优秀的PM，甚至我们可以在客户提出一些需求的时候尝试着从一个UX的角度去设计原型，如果具备前端的能力，也可以自己去Dev、UI，不断拓展自己的技能领域，使自己成为真正的全功能。

3

总结

真正的全功能，并不是单纯意义上让QA去做Dev，而是最大程度弱化角色的概念，逐步强调和培养技能多元化。如何把对需求的理解能力强化为业务分析能力，把质量控制能力强化为项目管理能力。强化自身的优势，跳出自己的舒适区，使自己能够轻松胜任。这样我们才不会在看到去QA和QA消亡之类的观点后，无所适从。

以下文章转自 QA请勿忘初心

Quality Assurance :The planned and systematic activities implemented in a quality system so that quality requirements for a product or service will be fulfilled.

Quality Control :The observation techniques and activities used to fulfill requirements for quality.

QA的工作涉及软件研发流程的各个环节，且涉及到每一位参与研发的人员，但质量保证工作又不涉及具体的软件研发细节，侧重于整个流程。

QC则侧重于点，利用各种方法去检查某个功能是否满足业务需求。

ThoughtWorks的QA则是这两者的混合体，既要保证开发流程的质量，又要保证Story的功能正确。

我来ThoughtWorks已经3年了，当过BQConf讲师与主持人，参加过公司内各类测试相关活动，也阅读过邮件中分享的关于测试的话题，大部分人关注点都离不开自动化测试，面试的QA也说想到ThoughtWorks来学习高深的自动化测试，仿佛自动化测试代表了整个QA界，我反对盲目的自动化测试，确切的说反对盲目的UI自动化测试。很多QA在自动化测试海洋里迷失了自己。

我要强调自动化测试：真的没有银弹。

QA的最终价值体现

Faster Delivery Of Quality Software From Idea To Consumer

确保项目的正确性

所以自动化测试只是其中的一小部分。

如上图顶部和底部的文字是对一个QA所能带给项目的总结：“我们在开发正确的产品吗？如果是，那么我们开发的产品正确吗？”所以QA首先需要在整个项目过程中不断询问所有成员上述问题，确保团队是在开发客户所需的产品，而不是自己YY出来的产品。

确保流程的正确性

Quality is not just in the software but also in the process.

质量从来都不只是QA的职责，而是整个团队的职责。但QA如果自己都不注重，不督促组内成员改进质量，再将责任强加于整个团队，那么产品质量又何谈提升与保证。

中间的图片从一个QA的角度表明了一个用户故事的生命周期以及QA如何参与其中每个环节。

首先BA和客户将要开发的用户故事列出之后，BA与QA可以一起结对编写具体用户故事的内容，场景与验收条件，利用自己对业务以及系统的熟悉度，尽量配合BA将用户故事中坑排除掉。

所有参与用户故事kick off的角色，都应该提前了解用户故事内容。在kick off过程中，提出自己对用户故事的疑问，尽量在这个阶段解决掉业务需求上的问题。

在完成kick off后，QA可以和开发人员一起结对编写unit test以及Automated Acceptance Tests，身为一个敏捷QA，我们起码要了解团队选用的单元测试工具，熟悉项目的技术架构，这样更好的便于我们把控整个项目质量，在与开发人员结对的过程中，帮助开发人员分析业务场景的分支，来确保单元测试覆盖的是正确的场景，而不是为了交代上级随便乱写的单元测试，这也可以帮助QA熟悉代码，提高编码能力。

当开发人员完成编码工作后，这时QA、UX、BA、开发人员一起检查用户故事，是否按照用户故事来检查是否完成对应的功能。UX也可发表对用户故事UI以及交互的一些看法，有任何问题及时讨论后，将问题尽早的反馈给客户。

当开发人员交付一部分功能之后，QA就可以做常规的用户故事测试，几个迭代之后，QA开始进行跨功能需求测试和探索性测试等。根据探索性测试的结果，QA可能会调整测试策略，调整测试优先级，完善测试用例等等。

上面这些QA实践貌似已经很完美,其实还差最重要的一环：uality Analysis 。每次发布后，我们总以为我们发布了一个完美的产品，但却总能在新迭代开发过程中发现之前存在的问题，历史总是惊人的相似，为什么，没有分析总结问题，以及相应的预防手段，那么同样的问题只会重现。

同时我们也要回顾下自己在工作中真的将这些敏捷实践都应用到工作中了吗？我想或多或少的都有所欠缺。对于一个QA来说，不应循规蹈矩照搬敏捷实践。例如，在kick off中，发现开发人员、UX对用户故事涉及的场景以及内容了解不清楚，QA也可能漏掉一些测试场景，那么我们可以在kick off之前，加入一个pre-kick off的实践，留出时间，让每个角色都能够完整了解用户故事。在kick off之中，UX没有办法完整的确认页面的字体大小或者颜色等是否正确，那么在sign off之后，我们也加入一个UX-test实践，帮助UX更好解决这些问题。

所以每个项目也应都有适合自己项目的敏捷实践，发现项目存在的问题，持续改进才是最佳实践。

再来谈谈自动化测试

上面的测试金字塔对于大家来说再熟悉不过了，对于自动化测试来说最有价值的仍然是单元测试，但对于QA来说无疑最复杂的。

大部分QA或者tester，仍然以UI自动化为重心。之所以反对盲目的UI自动化测试，是因为变化频繁的UI设计，投入产生比极低，这都应该让我们重新思考下UI自动化的价值。

我们需要一个实施UI自动化的正确方式：

能不用UI自动化测试就不用，梳理业务主线，只保留用户操作最频繁、交互最多的场景。
根据面向对象设计的原则，构建适合项目的UI自动化框架，无论自己编写框架，还是采用开源框架。
尽量采用独立测试数据，确保运行测试不受影响。例如采用mock数据库或者每次运行时还原测试数据库。
回到正题，面对自动化测试的大潮，QA应该关注什么？

编码规范。这是个真实例子，开发人员对于类名命名没有用Camel-Case，造成在Linux系统中部署不成功，Python中乱使用缩进等。其实这些都可以避免，例如开发工具加入自动检查，或者在CI上加入校验编码规范的步骤，采用一些工具就可以达到目的，比如jshint，RuboCop等。
结对完成单元测试或API测试等，一方面可以提高QA的编码能力，另一面可以给出开发人员一些建议，将单元测试覆盖到更多的场景。
例如，如果你们项目采用React作为前端框架，如果你不能理解React virtual dom 与jsx，当我们在写UI自动化脚本时，你会发现根本无法进行下去，日常中我们需要定位的元素全是这样：

所有的页面都是js渲染出来的，如果你懂jsx，就知道只需要在对于的Component render方法中更改加入id等元素就可以搞定。

控制单元测试覆盖率，100%的单元测试覆盖率当然是最好的，但如果交付压力大，和客户商量后，我们可以尽量覆盖业务主线，而不是为了达到覆盖率延误了交付周期。

再来谈谈质量分析

作为一个QA，我们不仅要检测项目中存在的问题，也要改进团队的实践活动，更重要的是预防问题的发生。

每次bug bash或相应迭代完成后，要分析统计，找出产生缺陷的环节，并采取措施防止问题再现。例如每次release或者bug bash之后，可以按照功能模块与bug类型进行统计划分，分析统计bug的成因，例如某次迭代我们bug数量激增，经调查，发现我们对某些模块的前端代码进行了重构，但缺乏相应的单元测试与集成测试，造成了我们没有及时发现bug。之后我们就对应的采取措施防止问题再现。
总结分析报告，及时反馈这些信息给团队。总结分析是一个长期的任务，每次bug数量的变动，都会直接体现整个团队上次迭代的开发质量，例如bug数量减少了，可以鼓励成员再接再厉。或者某几次迭代某些模块bug呈上升趋势，那么就需要组织团队一起讨论问题根源，采取措施防止问题重现。
利用代码质量分析工具，帮助我们尽早预防问题的发生。例如Sonar代码质量管理平台，可以帮助我们从代码复杂度，重复代码，单元测试覆盖率，编码规范等纬度来分析代码所存在的问题。当然也有其他的开源工具，像RubyCritic，/plato不同的语言都会有相应的工具。
在线监控，利用像newrelic，airbrake等监控工具对部署在本地或在云中的Web应用程序进行监控、故障修复、诊断、线程分析以及容量计划。这样不管产品环境有任何问题，我们都能及时响应，尽早修复，减低损失。
最后让我们再看看QA应具有那些能力与技能


软技能方面包括风险控制、辅导他人、沟通能力、分析定位等。技能方面则包括缺陷管理、流程改进、测试分析、可用性测试、性能测试、安全测试等。

本文转至：https://www.sohu.com/a/217947132_652348， 感谢作者的分享。