问题：

　　keynote里面作者说满足了三个条件之后，tester这个工作基本是多余的。

　　1、所有关于checking的工作（validation跟verification）都可以自动化之后。

　　2、可以让部分用户在cloud上面对开发的版本做测试。

　　3、开发者必须自己做测试，而且团队里面没有测试人员。

　　在测试领域里面，现在也着重于说testing只是提供Information，而且是一说明testing不是checking（http://www.developsense.com/blog/2009/08/testing-vs-checking/），所以Alberto Savoia说的test is dead到底是不是只是指checking？那测试以后的发展到底该如何呢？大家是不是也是觉得test is dead呢？

　　精彩回答：

　　我的理解是测试不会消失，而会改变形式。我同意上面的三个条件，但我不相信它们是普适的规律：

　　1、所有checking的工作都自动化的前提是得有人去写这些测试。对大公司而言，分离测试和开发任务是重要的，因为当软件规模达到一定程度时它必须要求术业有专攻。

　　2、不是所有的软件都能在云里，也不是所有的软件都能过早部署到用户环境。我们不能忽略不同软件类型对测试的不同需求。Google的大部分项目是网络应用，本身决定了它们的客户端部署往往相对简单，出问题了也容易控制。而以桌面程序为主要发布方式的软件公司则往往相对重视测试，比如微软。因为程序更新和升级的难度都大于网络应用。

　　3、开发者必须自己做测试是对的。但大型的软件往往很少给开发者机会控制整个系统全局。而仅仅是单元测试和小组件测试，是不足以确认软件的整体质量的。

　　我粗粗地浏览过题目说明里这篇文章（http://www.developsense.com/blog/2009/08/testing-vs-checking/）。我得说我同意作者看法中的绝大部分，测试的存在不是仅仅一个检查程序，提供信息是更重要的事情。唯一的区别是我不认为Testing和Checking的界限那么清楚。那么下一个问题是：这里说的信息，究竟是什么？原文的作者并没有具体地展开。

　　我的理解是，测试的目的是为程序开发提供一个有效的信息反馈系统。正像我在其他一些回答中提到的，测试需要为开发和项目经理提供如下的信息：

　　● 精确到程序各个组件的bug的变化趋势。这个信息可以告诉我们各个模块的质量跟踪情况和需要投入的资源。这主要通过完备的功能回归测试实现。

　　● 找到特定的极限情况，并设计自动化测试。这些测试有些可以告诉开发这个软件某个特定方面的整体能力，有些可以告诉开发某些特定模块的健壮性。这种测试的典型例子包括一些特定的测试门类，比如压力测试或fuzzing。为什么要强调自动化？因为这些领域内我们除了自动化测试之外别无选择。