阿里集团 1 + 6 + N 1+6+N 1+6+N 的组织变革后，各个业务单元都独立承担了经营压力。技术团队的规模更小、更敏捷，这对于原有一定规模的质量团队带来了较大的挑战。
最近拜读了很多集团测试大佬总结过往工作经验写下的文字。
我想，自己从事测试工作已经十几年，绝大部分工作历程是在阿里度过的，经历了测试团队的分分合合，见过山川大海，也走过土丘洼地。借此机会，也对 “软件测试的价值” 做个探讨，也希望有机会跟团队一起走出当前的周期。
以前跟同事聊天时说，一个创业团队是不需要测试的。包括太禅老师文章中关于 “来往” 的那段，也讲了同样的道理 “我觉得在架构还没稳定下来，一切以业务为先的团队中，想发挥测试效能还是比较难的，测试提效离不开研发流程的规范和交付标准的提升，不然只能陷入到人海战术的汪洋大海中。” 对于初创公司来说，最重要的是生存，是营收。而质量是大多数业务 Break even 后才需要追求的东西。
我们也发现，质量文化在工业时代就已经存在了，而且是伴随着第一天生产就存在的。对于工业生产来说，生产的品质决定着产品的良品率、成本等重要的经营指标。在软件工程的初期，质量同样也很重要。彼时的软件还是有点像工业品，以离线的方式来进行交付，严格而规范的过程，需要工程师一次性把质量做好，才能规避很多业务上的风险。
但到了互联网阶段，软件是以在线的方式来进行交付时，在大多数互联网产品的发展的初期阶段，往往是在不断试错的过程。这个阶段的目标是降低试错成本，从而更快的找到和满足用户痛点需求。对于用户规模 DAU、业务增长 GMV 的诉求，远高于对质量的需求。因此，在业务发展的初期，质量成为了一种奢侈品。除非极其重视质量的互联网创业团队才会在这个阶段在质量上做大量的投入。
但很多事情也不是绝对的，最近跟团队中音视频的测试 TL（Team Leader）沟通。她在音视频领域中工作了十几年，前十年在一家通信行业知名的外企，五年前跟随着原来的技术主管出去创业，一直做的是音视频产品，她还是负责质量工作。
我问她，音视频技术在过去的这十几年中有什么本质的变化吗？其实核心的仍然是 RTC（Real-Time Communications）这样的实时音视频通信技术，但原来的使用场景依赖于专业的终端设备，而这些年 RTC 更多的运用在如钉钉、Zoom 等互联网产品中，用户使用的门槛更低了，但同时终端设备的复杂度更高了。
我继续问，为什么在创业团队中还需要你这支质量团队呢？对于音视频产品来说，质量是一种产品特性，而且是最重要的一种特性。我们在使用一款音视频产品时，除了经过互联网改造后的创新功能，最基本的需求仍然是 “音画质、卡顿率、清晰度” 等指标。而这些指标恰恰都是质量上的指标。
因此，对于这样一类的产品来说，质量是必须的，而且能够赋予产品很高的竞争力和壁垒。
摘取了一些关于行业中普遍认为头部的音视频产品的用户评价，绝大多数也印证了上述的判断。
Z’s audio is pretty great though. I don’t know how they get around the latency issues. It seems impossible for musicians to be able to play together in real time from multiple places around the globe. Somehow Z pulls it off really well.（Z 的声音还是很棒的。我不知道他们如何解决延迟问题。音乐家似乎不可能在全球多个地方实时一起演奏。不知何故，Z 确实做得很好。）
It’s funny how people can hear people differently, though. After a couple of listens of the clips for the final verdict, I thought that the Teams audio sounded much better than the Webex. I do have some hearing loss in the upper registers, so that may somehow be affecting my perception of it since you said Teams sounded “tinny”, but I guess it is a little subjective.（不过，有趣的是，人们能听到不同的声音。在听了几次最终结论的剪辑后，我认为 Teams 音频听起来比 Webex 好得多。我的高音区确实有一些听力损失，所以这可能会以某种方式影响我对它的看法，因为你说 Teams 听起来 “很小”，但我想这有点主观。）
I think that in community work with less able, often low income, computer users I see that available bandwidth has a big effect on user experience. A future video look at reducing bandwidth and seeing who gives up on video or sound first could be helpful. Thanks.（我认为，在能力较差、收入通常较低的计算机用户的社区工作中，我发现可用带宽对用户体验有很大影响。未来的视频着眼于减少带宽并看看谁首先放弃视频或声音可能会有所帮助。谢谢。）
I was really impressed by Teams video superiority; given that and with the audio being all “pretty good” (IMHO),I’d chose Teams. I also value Teams integration with the MS Office tools for easy of use. This was a missing component of the bake-off.（Teams 的视频优势给我留下了深刻的印象；鉴于此，并且音频都 “非常好”（恕我直言），我选择了 Teams。我还很看重 Teams 与 MS Office 工具的集成，以便于使用。这是烘烤中缺失的一个部分。）
I work with Teams all day long and because of the interaction and collaboration with Microsoft apps it’s the best in my opinion. But I believe Z is really friendly simplicity. Webex does the job.（我整天都在使用 Teams，由于与 Microsoft 应用程序的交互和协作，我认为这是最好的。但我相信 Z 确实是友好的简单。 Webex 可以完成这项工作。）
For our international organization, the stability, features, and ease of use determine the platform we use. In this regard, Z Meetings and Z Webinar outrank Webex. Teams is an application in a different category.（对于我们的国际组织来说，稳定性、功能和易用性决定了我们使用的平台。在这方面，Z Meetings 和 Z Webinar 的排名超过了 Webex。 Teams 是一个不同类别的应用程序。）
这个阶段，阿里很多测试同学觉得，质量是不是突然不重要了？
我其实也有过这样的困惑，也跟一些行业中的朋友交流过业界的情况。答案是未必，比如某些大厂过去几年一直在做测试的拆分，但面临一定瓶颈后，也开始有些回调。某些大厂还处在业务的快速发展阶段，反而追求更为专业的质量能力，等。
其实，我在阿里工作的这些年也经历过分分合合，从金融到电商，再到现在。不同业务对于质量的诉求是很不一样的。这也体现在开发测试比上，从最开始的 2 : 1 2:1 2:1 的开发测试比到现在 20 : 1 20:1 20:1，我都经历过，也挺神奇的。很多 CTO 会关注开发测试比，什么样的比例取决于业务特性，以及处在什么样的发展阶段。可能优秀的测试主管能够力挽狂澜，创造更多的可能。但从最高的业务视角来看岗位设置时，还是看这个岗位所创造的核心价值。
在不太变化的研发过程中，不同的开发测试比例背后，变化是质量活动的取舍。在
20
:
1
20:1
20:1 的团队和
2
:
1
2:1
2:1 的团队在质量上的取舍肯定是不一样的。如果在仅有的资源下，在集成测试阶段将灰度用到了极致。只有在更低的开发测试比例或更高的测试资源投入下，我们才会讲到质量的左移或者右移，才会讲到质量的全生命周期。
所以，同样的这张软件生命周期图，测试在里面如何开展工作，取决于你看它的方式。
在回答这个问题前，我们回归到测试工作本质上。
测试的目的就是以最少的时间和人力找出软件中潜在的各种错误和缺陷，证明软件的功能和性能与需求说明相符。简单来说，测试是用最高效的手段来证伪。
前些年当算法在电商领域运用得炉火纯青的时候，我认为算法的不可解释性和结果的不可预测性是给测试这个行业带来的最大挑战。因为，这些构成了对测试最本质的 “证伪” 的颠覆。但没有想到，经营责任制和组织变革给这个专业带来的冲击更早一点。在经营责任制下，如果一个岗位只是用来证明自己生产的产品 / 技术 / 被测对象是错的，显然是无法立足的。任何一个岗位都需要思考所带来正向的商业价值。
我们还是要回答这个问题，从业务的视角，我们为什么需要测试？当年，我第一次汇报给开发主管时就想过这个问题。今天翻了一下以前的总结，时过境迁似乎也能够适用。
我们假设如果完全没有测试的话，会带来什么？
缺陷一定会存在于代码中，特别是模块间和系统间的 N2N 问题。如果没有测试人员，测试的工作仍然会存在，要么由开发同学来完成，要么由用户来测试。
完全由开发来自测，大概率会降低项目开发的效率，同时由于工作思维方式的不一样，一定会有大量 N2N 的缺陷被遗留到线上，增加修复成本。如果有专业测试人员参与到研发活动中，无疑会提升整体的研发效率。
而用户测试是互联网发展过程中的一种尝试，对于新功能的快速迭代上线和测试成本之间取得较好的平衡，但如果大量的依赖于此方法，会造成被灰度用户的大量投诉，从而提升售后成本。
（但坏消息是，有可能管理者要的是直接成本，没有耐心看到综合性效率。）
上述章节提到，不同的业务对于质量的诉求是不一样的。比如金融行业，对于质量几乎是最苛刻的，如蚂蚁的故障体系中一直在执行一分钱的资损就是 P1 的标准。对于金融客户来说，无法接受存放着资金的系统是不安全，不可靠的，这也是一家金融公司的品牌。
其次是决定着客户生产类的业务，如淘宝的交易系统、营销系统都承载着客户每天的业务生产过程，如果系统出现的错误，影响的可能是客户的营收。因此，这些公司和业务在早期阶段就会把质量要求提到较高的水平，随之而来的是需要有一个专职的测试团队来承载公司层面的目标。
（同样的坏消息是，质量不出问题你就很难看到这项价值，但出问题你估计也没机会看到这项价值。）
我们在互联网企业，可能很难去想象到测试跟合规还能有关系。但很多企业因为审计、评级等原因，是有合规的需求的。比如我们就经常收到企业客户提出需要我们提供标准的测试报告。
测试团队在过去十多年的发展过程中，从质量保障不断往研发效能的方向拓展。我们做了很多测试工具、平台，解决研发效能中的各种问题，并证明自己能够产生正向的价值。但我们也存在一个问题，做的测试产品好像总是跟随着团队的调整而不断消失，没有足够多的沉淀，跟国外相比我们还是缺少一些优秀的测试框架、工具、产品。
前两年还写过这样一段文字。
什么样情况下一个团队会消亡？一种是被技术变革的洪流滚滚碾过。随着技术的发展，可能这个团队、这个岗位已经没有存在的价值了。而软件质量团队虽然经过分分合合，但我觉得至少到今天为止，仍然在发挥着很大的价值。甚至通过内建质量 / SRE迸发出更大的生命力。
但没有想到今天在阿里对于测试的冲击会如此之大。虽然谈不上消亡，但足以打击很多测试开发工程师的信心。
作为职能团队，能力的横向复制是最恰当的事情。但 1 + 6 + N 1+6+N 1+6+N 背后是组织更小更敏捷，测试团队的组成单位也会更小，有可能只是几个人的规模。疲于完成业务测试，很难通过（路径二）在有规模的测试部门中横向输出自己的工具、能力来获得价值和认可。转而需要（路径一）寻求个人 / 团队能力边界的拓展，或者更深入的掌握业务来提升自己的职业壁垒。
当初在 1688 的时候，有机会以质量、SRE、PMO 三位一体开展工作。以前总觉得是自己的能力，其实更多还是来自于技术发展的机会。
在面临着业务价值的挑战，特别是当经营责任进一步往二、三级部门压实的情况下，测试所承受的压力也很大。我们需要把质量当成一种业务，逼迫自己去思考去不断探索和深化质量能够给业务带来的直接帮助。
面对变化，质量的工作可以分为三部分：
业务质量是我们的基础，只有业务能够认可我们的价值，我们才有可能活下来。
做好业务质量只是完成了最最基本的工作，除此之外，我们仍然需要沉淀出通用的质量能力，要有更专业的软件工程视角来解决整个技术部的问题。
除此之外，体验是更维度的质量，我们希望通过体验的 NPS（Net Promoter Score，净推荐值）来链接质量和业务。
NPS 的提升有一定的专业性，本文不详细展开。
在更专业的软件工程能力方面，我们也在做一些探索。
找到测试能力能够服务于客户的机会点。我们会从一些小的客户诉求开始，如上文提到的测试报告，未来我们希望可以提供更多深度的产品工具。
如何将各种前沿的技术如大模型应用在测试领域，让测试更加唾手可及。
例：通过大模型去自动生成自动化脚本，让自动化测试更加唾手可及。
互联网时代的产品可能拼的是创新，对商业需求的洞察。但会不会有一天，互联网技术会像工业技术一样，质量也会成为某一家公司某一个行业可以用来突破的路线时，那时质量一定能够成为皇冠上的那颗明珠。
本文转载于【阿里技术】公众号：《阿里十年总结之软件测试的价值》，原作者：傲野
