瓶颈：测试工程师该如何进行职业规划
但很多测试工程师在工作两三年后就会发现，似乎该掌握的业务知识已经掌握了，该熟悉的测试技术也已经熟悉了，就是不知道该如何进一步深入，工作变得缺乏挑战和成就感。我们姑且称这种情况为“三年之痒”。
本来在职业发展的过程中，遇到瓶颈是一件很正常的事，但测试工程师在遇到瓶颈后似乎更难突破。
各种测试群、技术论坛和博客上不乏“测试无技术”“测试无前途”的论调，测试似乎成了一个没有发展方向和前途的行业。如果一直无法打破，只能靠惯性前行，“痒”就变成了“坎”。很多优秀的测试人员在这个时候选择了离开。
这是一个很奇怪的现象：一方面是测试的队伍迅速壮大，高歌猛进；另一方面在测试面前又似乎横亘着一个迈不过去的坎。我想这背后有一个重要原因，就是测试技术在中国的发展过于迅速，反而导致从事测试工作的人们对测试的理解存在偏差，即使是测试工程师，对测试的优势和劣势的认识也不足。测试工程师在遇到职业发展瓶颈后很难取得有效突破。
本书的第一部分将和大家一起深入聊聊软件测试，探索测试的优势和劣势，厘清测试的发展方向，对测试工程师该如何进行职业规划提出建议。
第1章测试工程师的“三年之痒”
1.1软件测试发展简史
其实软件开发出现时就有软件测试了。不过最初的软件测试一般是由开发人员自己完成的，投入极少，那时的测试叫“调试”更为恰当，还称不上真正的软件测试。
随着软件行业的发展，混乱无序的软件开发过程已经不能适应软件功能日益复杂的现状，“软件危机”爆发。1968年秋季，北约召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱软件危机的对策。在那次会议上提出了“软件工程”的理念。随着软件工程的发展，软件测试也开始逐步发展起来，图1-1总结了软件测试发展进程。
图1-1软件测试简史
1975年，两位软件测试先驱JohnGoodEnough和SusanCerhart在IEEE上发表了《软件数据选择的原理》一文，将软件测试确定为一种研究方向。此时软件测试普遍被定义为“证明软件工作正确的活动”，这个理念被简称为“证实”。
1979年，GlenfordJ.Myers撰写的《软件测试的艺术》一书出版（该书到现在已经出版到第3版，依然被大多数软件测试人员奉为经典）。该书结合测试心理学，对测试重新进行了定义，认为测试是为了“发现错误而进行的活动”，这个理念又被称为“证伪”。“证实”和“证伪”至今依然是软件测试领域重要的理念，对测试工程师有着深远的影响。
1983年，另一本软件测试的重量级著作《软件测试完全指南》（由BillHetzel撰写）横空出世。这本书指出：“测试是以评价一个程序或者系统属性为目标的任何活动，测试是对软件质量的度量。”至此，人们开始意识到，软件测试不应该仅在事后用来证明软件是对的或是不对的，而应该走向前端，进行缺陷预防。
20世纪90年代，软件测试开始迅猛发展。自动化测试技术开始盛行，软件测试开始向体系化发展，测试成熟度模型（TMM）、测试能力成熟度模型（TCMM）等开始出现。软件测试体系日益成熟、完善。
2002年，Rick和Stefan在《系统的软件测试》一书中对软件测试做了进一步定义：“测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程。”这进一步丰富了软件测试的内容，扩展了软件测试的外延，测试进入“全生命周期测试”时代。
1.2敏捷开发模式下的软件测试
就在软件测试日益成熟的同时，市场对软件产品又提出了新的要求：既要质量高，又要交付快，还要适应不断变化的用户需求。瀑布开发模式变得很难适应，常常让项目陷入困境，第二次软件危机爆发。敏捷开发模式应运而生，逐渐成为流行的研发模式。
敏捷开发模式的发展
2001年，17位敏捷运动发起者在美国犹他州签署了《敏捷软件开发宣言》（简称《敏捷宣言》）。随后二十年的时间里，敏捷开发模式在全球范围内发展，迭代、持续集成/交付、DevOps等逐渐成了新的工程标准，不断提升研发效能。
在《敏捷宣言》发布的同年，中国的敏捷先行者就开始尝试将敏捷开发模式引入中国。2008年，几个通信大厂（诺基亚、爱立信、华为、中兴）开始进行敏捷开发模式转型，互联网行业巨头BAT也开始推行敏捷实践，敏捷开发模式在中国开始快速传播。
敏捷开发模式对测试产生了深远的影响。
在瀑布开发模式下，很多公司都有独立的测试部门，到了测试阶段，开发人员会把集成了所有功能的版本一股脑儿提交给测试人员来测试。当然提交过程也不会那么顺利，开发人员把提交版本给测试人员，测试人员测试不通过，会把版本再次退给开发人员，来来回回“拉锯”好几轮，测试人员才能正式开始测试。那时普遍认为测试人员要对产品质量负责，好质量是测出来的，所以开发人员调通基本功能后，就会等着测试发现缺陷，通过缺陷来驱动代码的优化和重构。到了发布的时候，测试人员对“产品是否可以发布”有一票否决权，测试人员和开发人员经常为了缺陷的处理方式争吵，彼此就像隔着一道墙。而敏捷开发模式推翻了这道墙。
LisaCrispin和JanetGregory在《敏捷软件测试：测试人员与敏捷团队的实践指南》一书中是这样定义敏捷测试人员的：专业的测试人员，适应变化，与技术人员和业务人员展开良好协作，并理解利用测试记录需求和驱动开发的思想。他们具有优秀的技术能力，知道如何与他人合作以实现自动
化测试，同时也擅长探索式测试。他们还希望了解用户在做什么，以更好地理解用户的软件需求。
在敏捷开发模式里，质量也不再是测试的事情，每个角色都要为自己那部分质量负责，每个开发人员都要自己去测试来确保自己的提交不会破坏系统，自己想办法去优化重构。开发人员和测试人员的关系，也从对立变成了合作，进而融合，测试、开发人员的比例从1∶2降到了1∶10，有些团队甚至不再设置专职测试工程师。
在瀑布开发模式下，产品发布周期通常是“大几个月”或是“年”，而敏捷开发模式要求“几周”就要发一个版本，这种增量式、小步快跑的版本发布节奏，让自动化测试变得非常重要，甚至成了影响敏捷开发模式成败的几个关键因素之一。
如果说敏捷开发模式推翻了开发和测试之间的墙，那么DevOps（开发即运维）又进一步打通了开发、测试和运维环节，通过持续集成（CI）、持续交付（CD）的自动化流水线，再次缩短了产品发布周期，可以做到每日发布或者每日多次发布。在DevOps开发模式下，自动化测试也进一步发展为持续测试，这使得缺陷在产生的时候就会立即被发现。测试也从瀑布开发模式下的后端验证，发展为全流程下无所不在的测试，如图1-2所示。
图 1-2 不同研发模式下的测试
敏捷开发模式聚焦为用户创造价值（Lean），希望践行者们具有如下价值观（Scrum）：承诺、专注、开放、尊重和勇气。
这使得敏捷团队中的测试人员，只要有想法、有能力就可做任何有利于用户或团队的事情，而不用担心测试的身份：
测试人员可以直接和产品人员沟通交流，参与产品规划；
测试人员可以直接和用户交流，收集需求，澄清问题；
测试人员可以像开发人员一样去编码；
测试人员可以做工具，做自动化；
测试人员可以做流程，做质量改进；
……
这并非不务正业，测试本身就是一个需要系统思维和判断力的行业，局限在后端是做不好测试的。敏捷开发模式帮助测试人员打破了限制测试视野和发展的约束，但也给测试人员带来了新的问题和挑战。
