我们来看看一个测试工程师一天的工作：参加需求评审，根据需求编写测试计划，设计测试用例，准备测试环境和测试脚本，开发提测延期后在被压缩的测试时间内根据用例执行测试。期间要和产品确认需求，跟进开发改问题。还要处理变更的需求，然后修改测试用例，对于改动的已经测过的地方又要评估回归范围。有时甚至因为项目上线时间已定，测试同学提出了风险都没用，测试用例都没时间执行完，只能挑主流程回归执行完确保没有重要问题，然后就发测试通过报告提上线单。这样测试工作是在证明软件是正确的（正常场景），而没有通过探索去发现更深的场景，以及异常场景。
测试的目的是尽早发现缺陷和尽量多地提供测试对象相关的信息。是为了证明程序有错，而不是证明程序无错。如果你只是在证明程序无错，那你就是在验证，就是在checking，而不是在testing。如果只需要验证的话，那么完全不需要测试：产品对业务更熟悉，他们可以直接验收；开发对代码更熟悉，他们可以自己执行。测试工程师的价值在于能高效地发现需求、设计、流程上有缺陷有风险的地方，不仅要做好质量保证，还要做好质量控制。软件的缺陷是不可能发现完的，在一定时间内，测试时间越长，遗留的bug数越少，但是超过了这个时间，bug只能无限接近于零，永远不可能等于零。花费这么长时间去测试是无意义的，而且项目也不可能给测试这么长时间；把所有bug发现出来也是无意义的，所以我们测试要做的是基于风险的测试。
要做好这一步，前提是我们有足够的时间做探索性测试，而每次测试中我们不得不花大量的时间回归一次原先的主流程、重要场景用例，这就需要我们的自动化测试足够稳定和完善，可以把人力从重复的劳动力中抽离出来。 但是，现在谈到测试大家就会想到自动化测试，谈到功能测试大家就会觉得很低端。这是本末倒置的。其实低端的不在于功能测试，而是你只会按照测试用例一条一条地执行用例，你只是在checking。将你负责的业务中P0和P1级的功能和场景用脚本实现，同时加以有效的断言，能将你从这部分工作中释放出来，测试人员再去做更多的异常测试、非功能性测试等。用探索性思维去做测试才是测试人员真正的价值所在。只推崇自动化测试也是畸形的，衡量一个测试工程师的标准不只是他掌握多少门开发语言，也不只是他能开发多少框架和工具，更多的是他的测试思维。回到前面的：测试的目的是尽早发现缺陷和尽量多地提供测试对象相关的信息，自动化测试只是辅助提高测试效率的方式而不是目的。
测试枯燥吗？测试没有需求调研、产品设计的趣味，也没有设计架构的成就（但是你也需要掌握一些产品和架构思维），测试的魅力在于你通过掌握的信息和不断摸索的方式找出产品的缺陷、项目的风险并且将这些缺陷和风险一步步降低。如果你只是在一遍又一遍地执行测试用例，或者只是一条又一条地编写自动化测试，那当然枯燥，而且你不是真正地在测试。测试就是探索，测试思维，就是一种不断通过增量信息，对存量信息进行质疑和完善的思维。探索是有趣的。
