说真的，怎么会出现这种情况，构建软件的人为什么会对测试了解得这么少？为什么我们以前没有试图解决这一问题？作为测试人员，我们是不是过于执着于当前的角色，以至于小心翼翼地守护着通向软件测试智慧王国的钥匙？测试是否过于隐秘和晦涩，以至于开发人员无法找到他们所寻求的答案？开发人员是否过于习惯将这一“无聊”的阶段交付给我们，以至于他们认为这些是理所当然的？

　　添加测试人员是没有用的。让他们更早参加开发周期也没有用。在我们的产品中，开发人员和测试人员的比例是1：1，但是这些产品本身却没有体现出高可靠性。我们有些产品在开发时有着更加糟糕的开发人员测试人员之比，但是他们的质量很明显高于其他产品。我认为，在未来，我们会看到开发周期的角色分工没有什么好处。这种角色的分工甚至必然导致测试在开发工程中的延迟，从而不能发挥出它应有的潜能。

　　目前的测试文化和软件开发周期中的角色分工有问题，解决它的方法是合并开发周期中的角色。质量必须是人人有责。套用托尔金的话：“One role to rule them all！”

　　请你想象一下这样一个世界，每一个软件开发周期的人都掌握了测试知识。系统架构师知道测试，设计人员知道测试，开发人员知道测试，并且他们不停地将测试知识应用到他们所做的任何一件事中。这样做并没有让我们取消单独的测试人员角色，因为我们要确定某些测试的独立性，好让我们进行更好的测试。如果在整个产品开发过程中的每一个决策都问到了正确的测试问题，那么最终系统测试的完整性将达到一个我们目前梦寐以求的水平。如果项目中的每个人都理解测试，想象我们需要很少测试人员就可以达到这一水平。

　　实现这样一个测试乌托邦需要大规模的文化变革。测试必须要延伸到学术界，或者其他有程序设计课程的地方。开发人员在他们事业上取得进步的同时，这样的教育也必须持续下去，并变得更先进、更强大。我们需要促使这种教育达到一定程度，即软件开发项目的所有利益相关者都理解测试并且潜移默化地将测试应用到他们所做的任何一件事情中。测试工具终有一天也会支持这点。有一天我们会处于这样一种情况，即永远不编写不可测试的软件，这不是由于某些强势的测试人员造成的，而是开发项目中的每一个都自觉这么做。

　　测试在开发流程中如此重要，以至于它不能成为流程中的“扫尾工作”。在开发流程的早期，设计决策影响着测试，因为测试的解决办法在设计时就已经确定。测试如此重要，以至于不能把它交给一个独立的软件开发周期角色划分出来的角色，让他只致力于质量保证。相反，我们需要一场根本性的文化变革，让质量成为每一个人的责任，并把它的原则植根于我们所做的每一件事。

　　我弄砸了这篇文章的标题，我应当叫它“测试即软件”，因为我更想让它包含这层意思。日复一日的测试活动将提高到更高的层次，测试里的所有核心资产，例如测试环境，可重用的测试用例，将作为成品上架供任意取用。但这只是将来最初的形式，并且还略有瑕疵。

　　测试人员即设计人员

　　目前测试人员主要扮演着软件开发中后期的英雄角色，这种角色在业绩评估和分红时往往得不到赏识。在我们发现严重软件缺陷的时候，人们认为这是我们应该做到的……理应如此。在我们漏掉软件缺陷的时候，人们就开始提问题了。事情往往就是这样，你做了就没人理，忘了就会有人训。

　　这种情形将会改变，并且会很快地改变，因为我们必须改变。我的朋友罗杰？谢尔曼（Roger Sherman）——他是微软的第一个测试总监——将这种测试角色的变革比喻为毛毛虫变成了蝴蝶。这句话出自罗杰：“测试工作蜕变出来的蝴蝶就是设计工作”。

　　我完全赞同。当测试和测试技术转移到开发流程的早期，测试人员做的工作更类似于软件设计人员，而不仅是软件验证。我们将更多地注重设计软件质量控制的策略，它不是只适用于二进制运行代码，而是适用于软件开发周期的所有产品当中。我们将花更多的时间在确定开发流程中的测试需求，而不仅仅是执行测试用例。我们将监测和衡量自动化测试的效用，而不仅仅是构建和调试它们。我们将花更多的时间审核已有测试用例的状态，而不是构建新的用例。我们将成为设计人员，把软件测试抽象到更高层次，并在开发周期的早期进行这一工作。

　　在微软，这个角色称为测试架构师，我相信大多数测试工作是向着这个方向演化。如果已经读了“测试的未来”这个系列的前六部分，会赞同这一观点，在以前提到的变化中，首当其冲的应该是使以设计为中心的测试成为可能的变化。

　　这听起来像是一个不错的未来，但是已经有一朵乌云笼罩在这片云彩上。这朵乌云来自于软件缺陷种类和软件测试类型，对于这两方面，在2008年，我们都做的不错。没有太多夸张，目前我们善于找出结构性的软件缺陷（指的是崩溃、挂起以及同软件相关的错误，而不是和它功能相关的错误），而不是业务逻辑方面的软件缺陷。但是，在我这一系列文章里描绘出的未来，对于结构性的软件缺陷，我们将有无数的技术解决方案。这使测试人员不得不去对付业务逻辑方面的软件缺陷，可是对于这类问题，我不认为我们目前整个测试行业都在使用有组织、有目的的方式去对付它。

　　寻找业务逻辑方面的软件缺陷意味着我们必须要了解业务逻辑本身。理解业务逻辑远远不止包含与客户和竞争对手打交道，它意味着我们得将自己沉浸在我们软件涉及到的任何行业中；它不仅意味着在软件生命周期的早期进行测试，还要使我们自己涉足原型、需求分析、可用性等我们从未涉足的地方。

　　在软件生命周期早期的困难工作中，有些是测试人员从未经历过的。要想在测试一开始就有一个良好的表现，就意味着我们要面临这些挑战，并愿意通过学习新的思维方式，来看待客户和看待质量。

　　在软件生产线的前端，事情肯定和末端完全不同，在前端，越来越多的测试人员将发现自我的价值，就像是将来给现在让路一样，他们地位会完全颠倒过来。