记得在读研期间，企业导师曾经问过我们一个问题：“测试人员应该在何时进入项目中？”。彼时的我们尚未有实际开发经验，凭想象都答道是开发完成以后。那位在软件行业有着多年开发管理经验的资深专家说道：“同学们，你们一定要记住我今天说的话，测试人员一定要在需求讨论阶段就参与到项目中来。”
当时我们听到之后都有些惊讶，不知道测试人员在如此之早的时候就介入项目中能有多大的效益。及至工作多年，踩过不少的坑之后，再看Bob大叔在书中所提出的验收测试观点，终于明白当年企业导师那一番话的含义。首先是对验收测试的定义，传统看法认为是在软件开发完成之后对既有功能的验证与检测。Bob大叔认为应该将这一概念前置为需求的确认完成。
相信每一位码农都经历过需求变更的折磨，网上更有无数的段子调侃产品与开发的水火不容。其实这个难题并不是无解的，一个好办法就是在开需求讨论会时把测试人员也叫上。这样当产品说“我这里需要一个登录页面”时，测试就会对“这里我具体要测什么”提出疑问，在产品和开发的共同确认下在功能要求和技术实现上达成一致。
当然，这里又会有很多的疑问抛出来说测试人员已经忙得不可开交了，就开发完成的功能都测不完，哪还有时间去参与需求呢？其实这个问题的根源在于测试人员的很大一部分工作是在给开发填坑，之前说过如果开发没有以专业态度要求自己，开发过程中不做单元测试，开发完就扔给测试，这等于是在让测试帮开发去做最基本的功能检验。这显然是一种效率极低的方式，导致测试和开发把宝贵的时间都消耗在交流上了。
所以要从根本上解决问题则是开发要转变态度，目标不是让测试去找错误，而是要让测试找不出错误来。一个很好的手段就是构建一套金字塔式的自动化测试体系。自塔底向上分别是单元测试、组件测试、集成测试、系统测试、人工探索式测试。
单元测试在前面测试驱动开发章节已经叙述过，是软件系统的最底层实现逻辑。而组件则是在底层之上的独立模块。将多个功能相关模块整合在一起又可以进行集成测试。系统测试则是最终完成的软件功能，包含所有模块的整体测试。以上这些工作都应该是开发人员与架构师完成的工作，这样测试人员就可以解放出来参与需求讨论，专注于软件质量的相关工作了。