我知道很多同学看到这类问题，第一反应想要去寻找的就是作为测试角色，应该要如何如何去做？但是今天这里作为质量第一篇，不打算按照这样单角度去写，这类同学可以就此打住，如果在意的话，可关注后续文章。这里先做个申明，避免浪费您的时间。那么我们接下来就步入正文。

何为质量？仁者见仁，智者见智。我这里想说的是：质量不仅仅需要组合一起看，也需要分开看。分别来看质和量，其实它里面包含了目前所说的效能问题。

质量=质(单纯的质量)+量(数量)，就是为了交付尽可能多的保质(可运行)的功能给到用户。说到这就不得不谈软件质量的起源，它目前已经经历了如下4个阶段

一开始的项目测试是以开发调试为主，但是渐渐地，这种方式不足以满足当前业务的需求，进而将测试职能化，成为了一个独立的职业角色，这个时候测试的职责主要是业务测试，对到现在来说可映射为人们常说的功能测试，也就是点点点；接着随着软件规模的进一步扩大， 暴露出来的问题也各种各样，此时将测试进一步细分专业化，成立了各种专项，比如大家熟知的：自动化测试，性能测试，安全测试，兼容性测试等；但是随着市场的变化，这些固化下的流程不足以应变当下的环境，测试这边需要聚焦最终可交付的价值产物，而非过程产物，这个时候的测试就需要从单一的职责里面跳出来，往外辐射，对兄弟角色进行赋能，比如产品，比如开发，比如运维。我们常听见的测试左移，右移，接口前置等就是这类的一种表现。此时的测试已经从单一的职能仓同里面的一员变成了自组织项目团队模式里面的一员。

从上面的演变过程中，大家其实可以看出来，测试这个活动一直是有的，但是测试这个职能是后续演变出来的，到后面整个项目型团队组织的演变，让测试更多的是以一种角色的形式而存在，淡化了职能的概念。再加上后面盛传的去测试化，导致测试同学产生了非常大的焦虑。我个人理解测试这个活动会一直存在的，只是形式会发生变化，而我们需要做的是不断提升自己的能力去适应变化。

而“内建质量”会是重中之重。

敏捷开发的盛行，加快了需求到开发节点的衔接速率，在整个需求研发流程中，测试和运维渐渐成为项目瓶颈。伴随着devops的产生，以CI/CD为主线的各种工程能力工具发展大大提升了价值交付物在各个环节的流动效率。原来竖井下的管理方式会制约团结间的测试协作，此时需要各角色高效地运转以有效响应快速的业务交付的自组织项目型团队。这要求测试人员具备更好的研发及工程能力，向团队提供智能高效的执行，管理，度量质量工具，有效支撑内建质量，保障高效价值交付。