2.1.3 “角色”和“段位”
我在做测试绩效辅导的时候，曾经有一个困扰我很深的问题：要想一个测试团队始终保持一个良好的状态，对团队成员的有效激励是必不可少的，但是除了“升职加薪”，我想不出其他的方法。但是我不是老板，“升职加薪”并不是我能把控的（其实即使我是老板，能够做主，也不可能总是用升职或加薪来激励团队）。对一位软件测试工程师来说，他从一位普通的测试工程师新晋升为测试组长的时候，可能会干劲很足。但是一段时间后（或许是一年，或许是半年），他可能又会进入一个新的“平台”。如果此时既没有升职的可能，也没有加薪的机会，我该如何帮助他度过平台期呢？
如果换一个角度想这个问题，其实就是本章开头的那个问题：如果职位没有变化，工作两年的测试工程师和工作3年的测试工程师差别在哪里？工作3年的测试工程师和工作
4年的测试工程师差别又在哪里？
直到有一天，当读到了姜汝祥的《请给我结果》这本书中一个关于“秘书九段”的故事后，我突然找到了这个问题的答案。
“秘书九段”的故事
总经理要求秘书安排次日上午9点开一个会议。这件事需要通知所有参会人员，秘书自己也要在会议中做服务工作，这是“任务”。但我们想要的结果是什么呢?下面是一段至九段秘书的不同做法。
一段秘书的做法：发通知——用电子邮件或在黑板上发个会议通知，然后准备相关会议用品，并参加会议。
二段秘书的做法：抓落实——发通知之后，再打一通电话与参会的人确认，确保每个人被及时通知到。
三段秘书的做法：重检查——发通知，落实到人后，第二天在会前30分钟提醒与会者参会，确定有没有变动，对临时有急事不能参加会议的人，立即汇报给总经理，保证总经理在会前知悉缺席情况，也给总经理确定缺席的人是否必须参加会议留出时间。
四段秘书的做法：勤准备——发通知，落实到人，会前通知后，去测试可能用到的投影、电脑等工具是否工作正常，并在会议室门上贴上小条“此会议室明天几点到几点有会议”。确认会场安排到哪，桌椅数量是否够用；音响、空调是否正常；白板、笔、纸、本是否充分；自己的准备，在物品上、环境上，可否满足开会的需求。
五段秘书的做法：细准备——发通知，落实到人，会前通知，也测试了设备，还需了解这个会议的性质是什么，议题是什么，议程怎么安排。然后给与会者发与这个议题相关的资料，供他们参考（领导通常都是很健忘的，否则就不会经常对过去一些决定了的事，或者记不清的事争吵）。目的是让参会者有备而来，以便开会时提高效率。
六段秘书的做法：做记录——发通知，落实到人，会前通知，测试了设备，也提供了相关会议资料，还在会议过程中详细做好会议记录（在得到允许的情况下，做一个录音
备份）。
七段秘书的做法：发记录——会后整理好会议记录（录音）给总经理，然后请示总经理会议内容没有问题后，是否发给参加会议的人员或者其他人员，要求他们按照会上内容
执行。
八段秘书的做法：定责任——将会议上确定的各项任务一对一地落实到相关责任人，然后经当事人确认后，形成书面备忘录，交给总经理与当事人一人一份，以纪要为执行文件，监督、检查执行人的过程结果和最终结果，定期跟踪各项任务的完成情况，并及时汇报总经理。
九段秘书的做法：做流程——把上述过程做成标准化的会议流程，让任何一个秘书都可以根据这个流程复制优秀团队，把会议服务的结果做到九段，形成不依赖于任何人的会议服务体系。
这个关于“秘书九段”的故事给了我很大的启发。测试组长、测试经理、测试架构师、测试总监等，都是被赋予了不同责任的“角色”，“角色”的转变可以在一定程度上反映职业的发展，但是不能说“发展”一定要“角色”发生变化。从“秘书”变成了“老板”，是
“发展”没错，同样从“一段秘书”升级为“二段秘书”也是“发展”。
所以虽然我控制不了升职和加薪，但我可以通过“提升段位”来激励团队成员。这是我可以做到的。
反过来，每个测试人员，是不是都该自问一下，在当前的测试工作中，自己属于哪一段，以及如何才能进入下一段？
我和我的同事曾经讨论出了一个普通测试工程师的“测试六段”，这不是一个所谓的“标准答案”，仅供大家参考：
测试一段：能根据测试用例的描述步骤来执行测试用例，能对照用例的预期结果发现产品的问题，能够清晰准确地将问题记录下来后反馈给开发，开发能够读懂问题描述的
含义；
测试二段：对产品需求有一定的了解，能够根据产品需求分析、设计产品的测试用例，发现问题后能够进行初步定位；
测试三段：对产品的需求和实现都有较为深入的理解，设计用例时会注意用例的有效性，测试用例时会考虑使用自动化测试等方法提升测试执行的效率；
测试四段：深入理解产品需求和实现，理解产品质量，理解产品的隐形需求，对产品性能、可靠性、易用性等非功能属性的测试均有所涉及，并掌握其中的测试方法，会使用测试缺陷分析技术，会评估产品质量；
测试五段：不断追求最适合产品的测试技术，关注测试过程改进，推动产品测试技术的进步；
测试六段：走向前端，做缺陷预防，能将测试方法标准化，并固化为测试工具和流程。
读到此处的朋友，请你不妨也为自己量身定制一个“测试段位”，并在测试的职业生涯中不断地修正、丰富它。相信这个“段位”，会在测试职业发展中给你带来意想不到的帮助。
2.1.4 软件测试在质量领域的发展
软件测试还可以向“质量管理”领域发展。
很多人可能会认为“软件测试”和“质量管理”是可以画等号的。我们在讨论软件测试发展简史时，提到的软件测试理念，无论是“证实”还是“证伪”，其实都是为了“验证软件是否能够满足用户的需求”。而“质量”是什么？Crosby 认为“质量就是满足需求”，从这个角度来看，“质量”和“测试”在内部确实有很强的关联。除此之外，测试理念中的“缺陷预防”和质量管理的思想也是一致的。所以称“软件测试”是一种“质量”活动，是没有问题的。
但是，我们不能因此就认为“质量”活动就是“软件测试”。“质量”并不是软件领域独有的，早在工业革命时期，“质量”就开始发展了。当时的质量叫“质量检验”（QI），就是关注“产品能否符合工厂制定的标准”。随着社会生产力的发展，产品生产环境、生产能力的提升，质量也有了新的定义。“质量控制”（QC）的提出，标志着开始从用户的角度来评价质量。在ISO9000（1986，1994）中，又进一步发展为“质量控制（QA）”，“质量是设计出来的”“质量就是满足用户的需求”“客户满意度”成为新的质量发展方向。现在，质量进一步发展为“卓越运营”，质量已经被提到了企业战略的角度，“质量管理”也成了现代企业管理中非常重要的一个环节。
从上面这段论述中可以看出，“质量”是贯穿产品全过程的大质量，而软件测试关注的是“产品质量”的小质量。对企业而言，“产品质量”只是质量管理中的一个方面，除此之外，质量管理还需要关注“交付质量”和“经营质量”，最终目标是要达到“卓越运营”。
既然软件测试可以认为是质量领域的一个子集，软件测试自然也适合在质量领域发展。主要参考方向如下：
1. 产品流程设计
负责企业在产品开发、市场、交付等全流程体系建设。例如，著名的集成产品开发（Integrated Product Develop，IPD）流程。
2. 企业质量管理者
企业质量管理已经成为企业管理的一个重要组成部分。
质量大师朱兰把“质量策划”“质量控制”和“质量改进”称为质量管理三部曲。每一个步骤的具体含义如下：
· 质量策划：致力于制订质量目标并规定必要的运行过程和相关的资源以实现质量目标；
· 质量控制：致力于满足质量要求；
· 质量改进：致力于增强满足质量要求的能力。
企业质量管理者通过这三部曲系统地对企业的质量进行管理。质量管理体系方法可以概括如下：
· 建立一个以过程方法为主体的质量管理体系；
· 明确体系内各过程的相互依赖关系，使其相互协调；
· 控制并协调质量管理体系各过程的运行，关注其中的关键过程，规定关键活动的运作方法和模式；
· 理解为实现共同目标所必需的作用和责任，减少因为职责不明导致的障碍；
· 在行动前确定所需资源的需求；
· 设定系统目标以及各个过程的分目标，通过分目标的实现，确保实现预期的总目标；
· 通过监控和评估，持续改进质量管理体系，不断提高组织的业绩。
当然，这里的质量是我们前面提到的“大质量”的概念，不仅仅是指产品质量，要达到的效果是企业整体质量的提升。
3. 客户满意度管理专家
“客户满意”是产品成功的关键因素，没有之一。关注客户的声音，让客户满意，无疑对产品质量提升有非常重要的意义，“客户满意度管理”也受到越来越多的关注，成为质量管理的一个重要内容。
对“客户满意度管理”来说，重点是要识别关键用户的满意要素和做好与用户接触点相关的质量保证。
“关键用户满意度要素”是指通过对特定细分市场进行市场调查后，分析得出这类客户对特定的产品质量要求和服务属性，并把关键客户满意度要素作为企业产品与服务战略的输入，使企业最大限度地保持产品竞争力；而“用户接触点相关的质量保证”是指包含客户可以感知到的产品和服务，其中服务包括产品推广、投标达标、供货保障、工程交付、技术支持、备件支持和客户培训等。客户对任何接触点都会产生好或者不好的感知，所以需要定义各接触点的关键、标准动作，并确保执行到位，提升客户感知质量。
客户满意度管理，前提还是需要对用户有很好的需求和理解。和软件测试不同的是，这里的客户需求，已经不仅仅局限于产品，而是客户可感知的方方面面，涉及面会更广。对于软件测试工程师来说，往客户满意度管理方面发展，也是不错的选择。
2.2 软件测试工程师职业规划建议
上一节讨论了软件测试工程师有哪些可供参考的职业发展方向。本节主要针对软件测试在制订职业规划时可能会遇到的一些问题，提出个人的处理建议，供大家参考。
2.2.1 做管理还是做技术
软件测试在职业发展上可以概括为“管理”和“技术”两大类，这点大家已经比较明确了。现在问题是，该走管理路线，还是该走技术路线？
......
本文选自《测试架构师修炼之道:从测试工程师到测试架构师》第二章，本站经机械工业出版社和作者的授权。
版权声明：51Testing软件测试网获机械工业出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
