几年前，我的团队从瀑布模型转到敏捷模型，现在转到DevOps。
对企业而言，在生产环境一天多次部署新软件，最具挑战性的转型问题之一是需要革新测试。在持续部署和集成的时代，没有太多时间让QA团队发现问题并踢给开发人员。因此在开发结束后，产品上线前去测试程序的时代已经过去了。
在这段走向DevOps的旅程中，我想出了一个非常简单的框架，并且改变了我对测试的看法（然而我的主要使命是产品经理）。
从功能测试角度考虑，我们尝试去回答4个不同问题，有关它的成熟度以及它在产品生命周期里所处的阶段。
这是基本测试矩阵：
1) 我们应该开发什么？
在这个阶段，我们准备好了下一个迭代，我们通过用户故事分析了要开发的新功能。每一个故事描述了新功能的意图。比如：“作为一名用户，我想要把已有测试用例从excel导入到Hiptest里”。
好，但是我们实际上应该开发什么？
这就是我在过去几年发现的非常有力的一种方法---行为驱动开发。它能够让团队对我们应该开发什么的定义达成一致。所有项目干系人（测试人员、开发人员、产品负责人、市场部）进行合作：
· 产品接受准则 – 示例，
· 业务接受准则 – 我们想要验证的一些假设。
这就是向左摇摆。我们在新功能开发前定义测试。
猜猜看？我们用的是Hiptest来做行为驱动开发。就像他们所说的，吃你自己的狗粮吧（自己做的程序要自己用一下才有体会）。
接下来，我们开发团队开发了新功能和单元测试。我们做了探索性测试并在生产环境部署了新功能。
2) 这值得吗？
现在我们有真实用户手里的功能（或原型）。这个阶段要衡量业务假设是否得到满足。任何时候只要答案是否定的，那么就再次丢弃代码连同测试和迭代……
测试假设的一个好方法是通过衡量行为变化。比如：“这个导出功能能够增加10%的激活率吗？”衡量行为变化是我发现的评估功能影响的最有效方法。
监控现场客户行为也可以对我们的程序可用性给出很多领悟。一个几乎从来都用不到的按钮可能是放错了位置，一个弹出框在5秒后关闭可能是需要更多的娱乐内容，或者需要在更短时间内关闭。
因此前2步里最大的部分是有关业务发现（用行为驱动开发的方法）和业务验证（观察并度量）。
测试不是关于产品，而是关于业务和支持它的产品。
3) 如何自动化？
试验很成功，那么我们把这个功能作为我们产品的第一节分享课。现在是时候在测试上投入更多来确保大规模质量交付了：将行为驱动开发的测试自动化，做一些性能测试以及其他的安全性测试。
更重要的是，测试应该集成在持续集成过程中。他们会对没有预期到的变化产生的负面影响给出快速反馈。速度是作为评估测试价值时最重要的考虑因素之一。
4) 这可信吗？规模怎样？
严重的事情是服务器可能会down掉，程序不会。规模和可信度是大事情，测试必须是实时的。
这就是向右摇摆。
我们通常会监控两种特性：性能和可用性。
我们用工具（比如Appsignal）监控我们的程序并持续获取性能信息。这有助于我们看到一个新功能在部署到生产环境后是如何正确运作的。
在新功能部署之前花几天时间来调整性能可能纯粹是浪费，如果它首先没有达到客户预期的话。最好快速启用一个功能，在生产环境里测试它的行为，然后在开发过程中一旦所有假设都被验证就调整它。这就是“Experiment, test and learn试验、测试并学习”的格言。
同样重要的是，我们也有实时用户反馈（通过在线聊天）来提出那些可能没有被之前的工具发现的问题。有时候，错误的行为可能不是因为代码错误，仅仅是用户体验不好或者只会出现在达到特定数据量时。比如在Hiptest开始时，我们不会对显示的文件夹做任何种类的排序，我们还没有足够多的场景来发现问题，但当用户使用上百个场景时发现了问题。程序没有提出问题，只是惹恼了用户直到我们强制对场景按字母顺序排序。
测试摇摆
在开发活动结束后，产品进入生产环境之前，测试最大的部分已被事先执行。无论你多么难以抗拒，这段时间结束了。
如今随着DevOps的提出以及部署周期的增加，测试上下移动。这就是测试摇摆！
