软件的QA是质量保障的英文简称。
首先谈谈测试的价值。测试的价值朴素的看法，当然就是减少交付到用户手中的bug。有个名词叫做价值链——产品交付到客户手中，质量差就会损失品牌声誉，或者直接失去客户，这个价值链就没法有效传递。
QA的工作目标是减少降低这种情况，要提升产品交付质量。
但是这么描述并不完全。
我花了半年才测试一个版本，肯定不行，也许黄花菜都凉了，所以还有一个效率的问题。
QA的价值应当是合理利用适当的资源和成本尽可能减少交付到用户手中版本的bug。
这么说大体上是恰当了，但是还有一个要素需要考虑。Bug的影响级别是有区别的，有的bug无伤大雅，有的是致命的，取决于bug对用户价值的伤害。
再概括一点就是——QA(Quality Assurance) 质量保障的价值是合理地运用资源成本，尽可能减少软件错误对用户价值的伤害。
用户价值伤害少了，软件产品对用户的正向价值才能最大化，我们的商业转轮才能在和用户进行交换的过程中运转自如。
然后，说完价值，我们再看看质量保障是干什么。实际上在上面的表述中，已经可以推论——质量保障就是得要建立一个怎么控制成本和效率的方法论体系，去快速收敛软件产生的错误，以及有效预防软件产生的错误，除此以外，还要一套体系去衡量软件版本质量，获取用户反馈来迭代改进产品质量。
方法论的建立，不是凭空产生，那必须要了解现代软件的研发模式，以及了解软件错误是如何产生以及如何修复这些细节。
实践中，在软件生产过程中，每个环节都可能引起质量问题，bug可以产生于需求设计阶段，编码阶段，代码错误修复阶段等等。
公认的错误发现成本的一个观念是——软件错误产生越久，找出它的成本就越高——所以QA要尽量在软件错误产生的第一时间找出它。
受限于研发模式，测试人员不可能时刻出现在每个流程节点，尤其是编码阶段，旁边站着一个测试人员盯着是很奇怪的。所以就出现了QA活动属于每个研发流程角色都需要关注的事项。也就是说，产品要QA，研发也要QA，运维也要QA，不仅仅是测试在进行QA。
因此质量保障是贯穿软件生产全流程，贯穿研发流程每个角色的。
接下来，谈谈每个研发流程中的角色是如何做QA的？
以及下面一些问题：
软件生产过程中每个环节的QA怎么做的？
测试和QA的关系？
自动化和QA的关系？
DevOps和QA的关系？
软件生产早期，产品需求，设计，研发，测试，交付，这是一般软件的开发过程，测试会在某个环节介入，拿到待测试的版本，设计测试用例，执行测试，反馈问题。
这个环节会来回倒腾几次，最后在工期压迫下勉强交付。
到今天为止，很多软件的开发实践还是这个样子。
测试活动仍然还是质量保证的核心活动。大量的软件错误在这个环节拦截。
这种模式的特点——没有例外，基本都是工期很赶，版本反复处在测试，修改bug，提交测试的循环中。
在一些比较规范的公司，机构，一般会试图减少开发和测试这个环境的来回倒腾的次数。
用什么做法呢？
其一，提升提测质量。很多企业所谓的开发自测，准入用例
其二，测试尽早介入研发流程，在需求提出的源头就开始进行质量保证，包括需求时期的风险识别，研发期间的代码质量检测，提测前的冒烟用例等等
其三，研发颗粒度小一点。基于需求越大问题会指数膨胀的认识，开发需求可以按照一个一个story敏捷进行，这就是业界所说的敏捷模式。每次做一个很小的完整的功能，小保证代码逻辑不太多，完整呢是保证可以测试。这样小需求流完一个流程，下一个需求可以并行时间开发
但是，为什么很多小作坊还是很传统的赶工模式？因为做到这三点并不容易。
首先是办公室——如果以前大家都是赶工模式，并且赚到钱了，你很难说服所有人去改变，理由就是，我们以前那么做赚到钱了，并且目前还运行得不错，苦是苦了点
这就是为什么，很多地方要推动开发人员做自测，非常难。需要自上而下，进行很久的工程师文化建设。
当然，现在的大厂基本上都是已经被考核覆盖了，bug率会推动开发人员关注自己的提测质量，做法最直接的就是提测前自测。但是在小地方小公司，这一点好像并不容易实施，原因在于小公司的研发流程很紊乱，很多项目经理的工作目标就是如期交付，如果不够时间就加班解决，而且角色之间缺少章程和文化约束，一些开发人员认为测试是测试的事，我自己测了还要你干什么？
第二条，测试全流程保障也很难做。大公司也一样，一个测试的时间总是被充分瓜分，周一周二需求A，周三到周五需求B，排满了，而且排时间会默认忽略测试人员理解需求测试设计的时间，直接上的排期都是测试执行的时间。现状可能就是，测试需要加班来补充测试设计和需求理解这些活。
除非时间充裕，很少测试人员会有时间和精力去监控开发的代码质量，他们几乎把时间花在提测后成品的测试。当然需求阶段可能更是没什么精力和条件提出什么有价值的建议。
但是测试人员不管，可以开发管啊。
实践中，大公司的QA全流程，需求阶段由项目经理和产品研发的leader把控，有时候QA的leader也能叨逼叨逼几句，研发过程中建立持续集成流水线，进行代码commit级别的监控，每天集成，构建，跑自动化（这一步当然很少见）多数就到打包这一层，即使打包也有价值，至少说明你的代码可以编译。有追求的项目组，会有代码规范，引入一些语言级别的代码检测工具。
第三条是比较先进高级的做法，基本上我们很少见到。需求很少会拆得规范，某大厂曾经推行过，但是收效甚微，具体原因很难概述。反正做下来出现最搞笑的情况就是，一个开发经常一次提测给对口的QA是两三个，四五个story，然后其中某几个需求还有依赖，简而言之，拆了等于没拆
如果问测试人员，你怎么做质量保障？
他可能三言两语说不完。
说测软件包，太笼统，不够。
只好说全流程质量保障。
需求评审阶段，要参加，对功能可能出现的风险提充分意见；
研发阶段尽量推动可以单独测试的小模块提早提测，敏捷工作，没有流水线打包，代码检测的要尽早建立，低成本高收益；
研发的设计评审要参加，明确细节，提出可能出现的风险，明确测试点；
针对大需求要有测试策略和计划；
测试设计完成后，拉起测试评审，保证团队认知对齐。
这些事做完做妥当了，基本上版本不会出现什么大纰漏。
而且测试执行期间会很顺畅。
测试执行期间，勤记录，勤沟通，勤反馈。
最后产品验收，准备好测试环境，交付。
还没完事呢，作为全流程质量保证，交付之后就万事大吉，不可能的，还有重要的一环——监控体系和熔断机制。
通常这事好像是运维的事，但是实际工作中，QA还是要盯。版本交付之后，用户的反馈数据，线上监控体系没有的，不完善的，得即使建起来。一些关键的功能QA也需要有自己的业务监控，不能仅仅靠运维的基础设施监控。
熔断机制是指，出现问题之后快速处理的预案，最常见的就是回滚版本，或者紧急修复上线。
你们公司的紧急修复上线流程是什么？有没有？大公司肯定是有的。
梳理完之后，我们发现，QA好像不一定需要用到自动化。
是的，的确如此。
自动化要解决的问题是测试效率的问题，如果你点的足够快足够准，好像不是十分需求自动化；
如果一个自动化用例开发时间过长，你的第一个版本来不及自动化；
如果版本不稳定，上一个版本的功能经常被产品推翻，好像不是特别需要做自动化；
以下的问题没有标准答案，至少我见过不同做法的团队。
如果一个功能几百年没出过问题，关于它的测试用例需要自动化吗？
如果一个功能自动化的成本太高，它还有必要进行自动化吗？
如果一个功能测试用例自动化运行起来很不稳定，是放弃还是投入精力提升稳定性？
这些问题的考量都涉及到投入产出比——ROI，做自动化的收益和投入。
我们说了，质量保障的价值传递，涉及到成本和资源消耗的考量，如果一个活动成本过高，而产生的收益不够——比如，发现有价值的问题很少，或者误报率很高——那么这个活动就没有开展。
通常团队做自动化的正向动机——
- 回归测试真的是太多了——我们需要技术手段提效
- 不做自动化跟兄弟团队比较显得没什么技术，好像没什么技术产出，于是都想到造轮子和做自动化
- 老板逼的。老板总有一种思维或者说愿望，自动化可以帮他剩下几个人力钱
现实中只有1是真的值得做的。当然，2和3这些原因足够驱动一个团队去干自动化，但是最后的结果一般都不会太好，团队会发现他们的活没少干，而且更累，当然有时候可以获得很好的考评。自动化用例一代换一代，烂在仓库里，张三考评完，升职了，到别的组做领导，他曾经的用例一般就是烂在仓库，李四接手的时候，发现维护起来头都大，各种跑不通，代码包浆了，用了十年前的框架，老库，可能都不维护了，一跑起来满屏幕的红色，直接抛弃，发现产品研发没什么影响——而这都是在实际工作场景中很常见，很稀松平常的事。
最后说说测试工具。
测试工具是一种测试效率提升落地之后的产物，如果一个测试工具没有提效作用，这个工具自然就不能成立，会被抛弃，如果一个工具需要耗费巨大的开发成本，但只能在小场景使用，它的价值也不大，不能成立；如果一个工具的功能实际上已经有其它更成熟更被用户熟悉的工具存在，它当然也不太成立。这里所谓的提效，有时候不单纯是一种时间的节约，也可以是其它资源的节约。
以上论述，大抵上可以说，大公司面对拿来邀功请级的工具的一种评价体系：
- 有没有提效
- 有没有造轮子的嫌疑
- 关键的价值点，节约了时间还是什么资源，把什么麻烦进行软件化了
- 使用范围怎样，太小了没大价值。所以为什么工具组的人总是不遗余力去推广他们的烂东西（好东西会自动扩散，只需轻轻一推）
实践中不成立的测试工具是普遍存在的。
一般实践中的测试干活无非就是跟需求测试版本，做点自动化完成KPI，有的可能会做些bug分析跟踪，测试环境打理这种活，“高级”一点就是躲在角落上开发神秘的测试工具。
为什么说神秘呢，因为我经历中见过的工具，大多数都是某个时间点在群里宣传，我们做了一个牛逼货，领导看了点赞，大家好奇点进去用两下，发现要么没什么用，不知道他要解决什么问题，要么就是能用，但用着用着发现跟之前用过的另一个开源工具很像，就是换了一张皮，要么就是被领导按着头用。
测试工具一般是什么东东，其实说出来就不神秘了。
再谈谈测试工具的品类——
测试框架类，自动化测试框架，这个轮子稍微成规模的公司都会去造一把。这种工具的价值一般不大，我觉得大部分中小公司去做，是浪费资源，大公司做有他的理由，因为大公司团队大，一些小小的改进都会放大价值，但是前提是要把东西做的好。
某类测试专用的工具，比如移动设备的网络测试工具，性能测试测试工具，抓包工具等等。这类工具基本上都有比较多成熟产品，可以根据需要选用。大部分开发这类工具的，一般都属于重复造轮子。
测试管理平台——都喜欢做，有高T的地方就有人弄； 测试平台多数场景都会有价值，但是很少有人把这个东西做的很好
API测试平台——都喜欢做，有高T的地方就有人弄；API测试工具每个大公司都会搞，因为技术难度很低，更多是功能和易用性的设计，目前 Postman 比较流行，出于出圈的，能走出公司范围的。
总结下来，大部分团队，只有测试平台值得做。
测试平台的价值，可以概括出以下几点，看完这几点价值，也侧面说明了为什么测试平台为什么每个团队都应该有。
- 测试用例共享。没有测试平台，你们肯定是用在线文档，比如google doc或者飞书文档，腾讯文档去做这件事
- 内部测试脚本集成。没有这个平台，你们一定是甲开发完的小工具，乙要用的时候，丢给他。乙拿来跑的时候经常发现运行不了，需要处理一些诸如路径问题，硬编码问题，数据依赖问题，和库的问题，都是时间。在平台集成的好处很明显——点一下就行，平台化之后，张三能点，李四能点的成功率很高
- 测试数据共享。这个用例共享是一样的。
- 自动化用例管理。没有平台，自动化用例各管各的，大家在代码仓库维护，需要跑别人的用例，需要克服各种困难。当然分工明确，测试流水线完善这点问题倒也不是特别的严重
- 知识库。有价值的分享
实践中，测试团队会采用很多替代的方法做以上一些事情，比如用内网FTP服务器共享测试用例，测试数据，各种工具IM传递，但是产品成熟，流程完善的时候，有些做法会肉眼看到的低效，这时候开发一个测试平台实现一下以上一些基本的功能就很有必要了。
在测试行业，做测试工具是升职利器，但是这个行当说实话太卷了，做来做去就是那么些，以至于一个品类的工具五花八门，都做包浆了，但是没办法，这行不做工具很难升上去，很现实。但是作为价值而言，做工具应该是最没有投入产出比的事情，很多问题，明明可以用现成工具解决的，非有一个专职不管业务的人或团队在那儿coding。
有些大公司对于特定的平台工具，会设定专职的测试开发团队维护开发。测试产品本身已经是一件产品，实际上已经和测试关系不大了，打个比方，做一个财务软件的团队，他们本身也了解一些财务，但是他们本身已经和财务会计角色完全不同了，就是这个道理——业务测试团队自己做工具，就像财务人员自己开发软件。
现实中很多地方也有一种认识，觉得测试测着测着就得不测功能，转为测试工具开发。很难判断这是对还不是不对。业务测试的人，长年累月做业务，代码开发能力的确很有限，转为工具开发，已经可以认为是转行了。但是从被需求的角度理解，工具开发看上去很有技术感，实际上如果公司财务有问题，也是比较容易受到冲击的职业。
闲聊至此！
