测试人如何进阶管理岗位？谈谈我的理解

lsekfe

　在各种各样的公司或岗位上，有着三种人：遵守规则、见识规则、搭建规则的人。
　　大多数人都处于遵守规则的阶段，也就是执行人员，不论开发、测试等岗位，根据当前的管理体系去熟悉去适应去执行。
　　小部分人见识过各种各样的规则，这取决于不同公司的规模，为什么大多数公司喜欢大厂背景的人才，就是因为他们见识过完善的制度体系，学习能力快、人员素质高等原因。
　　最后很少一部分人处于搭建规则，当然搭建规则的人必须有个前提——见识过规则。
　　每一个公司都有自己的制度流程，从别的地方复制粘贴过来的并不完全能够运行下去，中间会出现各种各样的问题，最后导致断层问题，在不断改进后形成自己的规则体系，使公司更好地运行下去。
　　那我们从这一篇文章开始去了解为什么说体系建设是重要的，测试人员的进阶方向更不止一条。

　　常见的研发管理体系建设
　　我们先来了解下常见的管理体系有哪些，并且我们在其中需要做什么。

　　基于CMMI
　　CMMI体系实践其实更适合于以瀑布式开发为主导的项目开发及产品研发模式。它有两种表示方法，阶段式和连续式。这两种表现方法的区别是：
　　阶段式：把CMMI中的若干个过程区域分成了5个成熟度级别，帮助实施CMMI的组织建议一条比较容易实现的过程改进发展道路。

　连续式：将CMMI中22过程区域分为四大类进行覆盖：过程管理、项目管理、工程以及支持。对于每个大类中的过程区域，又进一步分为基本的和高级的。

这样，在按照连续式表示方法实施CMMI的时候，一个组织可以把项目管理或者其他某类的实践一直做到最好，而其他方面的过程区域可以完全不必考虑。
　　CMMI的表述方式不同，但其实质内容是完全一样的，是同一种方法的两种不同的表述方式，不管企业需要做什么样的评估，企业所获取的实惠应该是差别不大。具体要做连续性评估，还是做阶段性评估则要看企业对等级评估证书的具体要求。
　　笔者所在的公司虽然是CMMI4级认证，但实际工作中我们并不会完全按照CMM4去进行，对于CMMI认证其实完全贯彻很艰难，所以大多数采取到了投标资质上面有利于加分，对于运作上 to B的公司其实更加适合。
　　CMMI的体系管理模式中，笔者参与了质管部分工作与测试流程规范方面的体系建设。
　　从质量上来说包含了：产品质量设计管理、测试规范流程搭建与改进、质量控制与实施落地。
　　从测试中来说包含了：瀑布流的开始、过程中与结束。
　　结合质量管控同时在测试部门进行权重偏移，更好的说法就是测试部门完全独立并负责软件质量（SQA部门更注重过程），测试工作更加具体、测试流程更加严格。
　　这么说可能不够详细，那咱们分开来看看SQA与测试的关系。
　　SQA不等同于QA，他的活动主要在过程域中，也就是过程管理与改进（QA定义自ISO9000家族，而QA是SQA的关键环节）。
　　SQA的设立是有必要的，但并不宜做，具体原因有三点：
　　1、SQA是脱胎于软件服务行业，最主要的职能是根据CMMI来控制软件开发流程和质量，绝大部分流程在项目交付后就终止了，对产品的运维和服务一无所知；
　　2、而互联网公司更多的是产品服务型的，产品研发和运营都是核心，甚至可以说更侧重于运营，因为收入基本上都是来自于产品运营，产品研发需要更敏捷、更快速的迭代来响应，而CMMI过于严苛的控制会导致一定的延迟和损失（愿意牺牲50%的效率保全可能存在的风险，SQA即合理）；
　　3、现在互联网企业内部的产品研发也是在倾向于项目制，而非早先隔阂比较大的部门式运作。设立SQA，相当于是把部门内的监管职能抽取、独立出来，做整体上的掌控，可以减轻产品经理、技术经理相当大的管理负担，因为他们在这一块的专业管理能力还是相当欠缺的。
　　以上问题说明，SQA在保证质量这个大的话题下，工作要务实、能落地才行，不然就是空谈。
　　而笔者的观点是，质量保证这个事情是需要人去做的，但由谁来做因团队而异，所以说要搞定的人除了老板、开发部门头头，还有下面的项目经理、工程师一干人等，否则很难执行，且被敌视和边缘化。
　　那么，CMMI到底是什么呢？
　　通俗一点说，CMMI就是一套指南，做事的一般方法，改进质量的参考框架。我们参考它提供的方法，通过控制我们的项目管理过程，来达到提高软件质量的目的。

　　基于敏捷
　　有很多前辈们经历过2000年的CMM大潮，大潮过后逐渐出现的种种情况不得不让我们看向敏捷，现在大多数公司走向了敏捷模式，敏捷模式的核心是以人为本、拥抱变化。
　　在这个核心下，每一个该模式的公司开始了百花齐放（毫无疑问的是敏捷取得了巨大的成功，但敏捷这个词汇也成为了小部分人/公司的笑谈，小作坊的最后一块遮羞布）。
　　敏捷模式，真的是让人又爱又恨啊！
　　笔者参与的项目工作大多数其实都是在采用敏捷模式，但敏捷模式并不是固定的，可以这么说吧，每一个项目团队都有自己的一套敏捷方式，各种各样的方式造成了百花齐放。
　　废话不多说，那么我们先来了解什么是敏捷：敏捷是方式，不是目的。

敏捷是当前不少互联网企业、中小企业推行的研发管理体系，敏捷软件开发方法已经在现实实践中取得了巨大成功，受到了无数软件开发爱好者和软件行业管理者们的青睐。
　　主要理念是敏捷迭代、小步快跑、快速改进、拥抱变化、用户参与等等，是以人为核心、迭代式、循序渐进的开发方法。
　　敏捷宣言的核心价值观是：“个体和交互胜于流程和工具，可工作的软件胜于详细的文档，客户合作胜于合同谈判，响应变化胜于遵循计划。”
　　敏捷模式下的软件项目管理则能够欣然地面对变化、接受变化、欢迎变化，敏捷的目的就是使软件开发过程成为不断适应变化的过程，甚至能够通过改变自身来掌控变化、适应变化。
　　因此，从另一方面来说敏捷软件开发原则并不是普遍通用的，它的开发理念只适合短周期迭代、轻量级的产品与项目和敢于拥抱变化、重视客户价值的组织与团队。
　　然而敏捷开发方法并不是一种具体的开发方法或开发过程，它是一整套轻量级开发方法的统称，这些开发方法各自包含了不同的具体开发过程：

　　极限编程
　　极限编程是软件开发方法中最快捷的一种。团队通过持续测试方法和特殊计划方法与现场客户全面交流、获取快速的反馈，使团队发挥最大价值。

　　敏捷建模
　　敏捷建模描述了一种建模风格。在敏捷环境中，它能够有效地提高开发速度和产品质量，同时它又能够避免设计中过度的简化和对需求不切实际的期望。

　　自适应软件开发
　　自适应开发用一系列循环的假设、合作和学习周期来取代传统的瀑布模型。这种动态的循环为处于紧急状态下的项目提供了持续学习和适应的能力。自适应软件开发方法的特征包括关注任务、以功能为基础、迭代进行、有时间窗口、风险驱动和欢迎变更。

　　水晶方法
　　水晶方法力求通过减少纪律约束而使产生效率与易用性达到平衡，简而言之，虽然水晶方法不如极限编程那样高效，但是它更容易被贯彻执行；

　　特性驱动开发
　　特性驱动开发是一个由模型驱动的、短期遍历的过程。它不具有传统工程中冗长的设计过程，而是通过边设计边开发的形式来进行迭代完善，因此它非常适合被用来做小型项目的快速开发；

　　测试驱动开发
　　测试驱动开发强调任何功能的实现都源自于测试，测试代码是真实的业务需求的技术体现，开发人员根据测试代码编写功能的实现；

　　Scrum
　　Scrum 方法包括了一系列具体的实践和预定义的角色，Scrum 方法采用迭代的方式循序渐进进行开发，它是一系列敏捷开发方法中使用最广泛也是最为有效的一种。
　　虽然这些敏捷方法的具体名称、过程和理念都不尽相同，但是它们都以快速交付高质量的软件产品为目标，以满足客户需求为宗旨。
　　我们大致了解到了敏捷的理念，下面我们来看看敏捷测试人员的价值和发展。

对于敏捷模式中，测试的工作开展也是敏捷的，但工作内容又是分散的，2-4周的迭代周期，缩短了测试工作的时间，因此你不用再写一大堆的文档了，那么这个时候你就有了两种做法：

　　自上而下
　　生成一页测试计划，提炼测试点，编写测试用例，这个测试用例的颗粒度会很大，因此自上而下去进行时更多的会采取探索性测试。

　　自下而上
　　提炼测试点，更细致的编写测试用例去覆盖，根据这些测试用例去编写测试计划，这种方式其实更加去保证质量，但是对于周期工作无疑是一项挑战。
　　敏捷功能测试 = 新特性的手工测试 + 原有功能的自动化测试。
　　敏捷中采取自动化、性能测试工作，无疑是艰难的，快速的迭代很难保证这些测试手段成功落地。
　　项目采用敏捷方法，要获得成功，项目组中每个人都有很强的质量意识，具有质量的主人翁精神，特别是开发人员，每时每刻提醒自己——“质量是构建出来的”，与客户或产品设计人员进行充分沟通，遵守高度一致的质量标准。
　　敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个软件开发的过程安全的、及时的发布最终产品，敏捷测试人员因而需要在活动中关注产品需求，产品设计，解读源代码。
　　在独立完成各项测试计划、测试执行工作的同时，敏捷测试人员需要参与几乎所有的团队讨论，团队决策。
　　同时还指出作为一名优秀的敏捷测试人员，还需要在有限的时间内完成更多的测试的准备和执行，并富有极强的责任心和领导力。更重要的是，优秀的测试人员需要能够扩展开来做更多的与测试或许无关，但与团队共同目标直接相关的工作。
　　他将帮助团队其他成员解决困难、帮助实现其预期目标，发扬高度协作精神以帮助团队的最终获取成功。需要指出的是，团队的高度协作既需要团队成员的勇敢，更需要团队成员的主动配合和帮助。

　　两种测试团队模型
　　我们来根据常见两种测试团队模型来进行说明各自的优缺点。

　　独立的测试团队
　　这个就是闻名的与开发打架的团队。
　　好处
　　独立团队，还是能保证一定的“公正性”的，比如在测试的最终，横竖有人能不屈从于程序团队的要求隐瞒产品质量，而是的确会客观地评价质量。
　　坏处
　　常常有几个误区：
　　1、程序团队是用来开发功能的，测试团队是用来查找缺陷的，有了这个认知，要让两者打架就不难了；
　　2、更多的测试人员=更高的质量。许多公司拥有惊人的测试人员比例，程序和测试基本上能到1：1，这个已经接近了造航天飞机的水平，但程序团队就对质量不太在乎了，因为后面有人负责测试，有Bug漏掉还要担当责任，所以自己只管按自己的兴趣编写代码就是了，而留下的缺陷越来越多，自然就需要更多的测试人员来解决。

　　分散的测试团队
　　好处
　　每个团队都有测试人员，自然测试活动会被当作家里的事情来看待，有机会在很早的时候就启动测试活动。由于没有后继的测试活动了，也没有人可扯皮了，所以组内的测试活动的效果会比较好。
　　坏处
　　常常有这样几个误区：
　　1、人员不能共享，测试人员不足。基本动身点，还是认为这几个测试人员是来帮助解决缺陷问题的，因此他们极有可能成为局部的捡垃圾者。由于只能调用自己的测试人员，当然渐渐地几个人就不够用了，也需要更多的测试人员。
　　2、缺少总体质量的把关者。由于全部测试人员都被当作小组的负责质量的人，产品最终全部模块集成在一起的时候，质量由谁负责，就成了个问题。集成后如何验证整体业务(而非技术)，也是个问题。
　　通过以上的了解认识，相比大家已经有了一定的对比，那么我们来讨论下敏捷测试人员的素质能力。

　　定义质量
　　这应该是软件测试人员的基本职责。敏捷方法鼓励测试人员在Sprint计划的时候直接与客户交流，从自己的经验出发，共同为产品功能制定质量要求。

　　交流缺陷
　　敏捷过程强调团队中的交流。开发人员经常会专注于重要而新奇的功能，测试人员应该抓住细节，寻找设计中的“missing door”。
　　另外，开发人员使用单元测试来保证产品的基本质量，测试人员可以使用验收测试（Acceptance Test）来鉴定客户需求与实际成果之间的不一致性。

　　及时反馈
　　敏捷过程强调简单而高效。测试人员需要及时反馈产品目前的质量问题。这样一来，团队才可以立刻着手解决。
　　如果传统的流程是一周汇总一次状态的话，敏捷流程要求每天汇总质量问题。在我们的项目中，内部的测试报告会以网页的形式显示在内部站点上。每个团队成员能够随时获取。
　　另外，我们的测试框架提供——自助测试。即通过点击测试用例列表中的某个具体用例，开发人员不需要中断测试人员的工作就可以重现缺陷。

　　敏捷与传统测试的差别
　　我们可以根据下图列表进行梳理：

总体来说，敏捷测试中更要注意这三点：
　　1、明确验收要求：在产品需求明确、细化为项目时，应明确每个用户故事的验收要求；
　　2、跟踪处理缺陷：化整为零、尽早接入，根据测试需求，可开展单元测试、接口测试（具备代码阅读、检测能力）；
　　3、及时沟通反馈：加强沟通，及时反馈。

　　对敏捷的几个误解
　　在此根据个人经历及查阅了相关资料进行说明。

　　敏捷对人的要求很高
　　敏捷对团队人员的要求确实高，但也不是搞到了天花板甚至离谱，越来越多的公司一直在说，我们想优化下当前模式，但是团队人员的能力都达不到一个高度可怎么办？
　　也有的公司出现了一人多岗的模式，去全面锻炼综合能力——上一个项目你还是测试经理，下一个项目就成了需求。这样确实锻炼了你的广度知识能力，但是广而不精。
　　专人干专事、专岗定专责。敏捷人员的要求的高不是在广度上，而是在精度中体现的。
　　引用他人的话：撇开技术不说，有谁会觉得清楚找到项目开发流程、知道每位项目成员的工作内容、职责范围、产出，并清楚项目目标、需求、用户需要的开发人员（含设计师）很容易呢？

　　敏捷不需文档，也不做设计
　　这个误解从XP开始就没有停止过，XP鼓励“在非到必要且意义重大时不写文档”。
　　笔者听到最多的一句话就是：“程序大于文档，我写文档干嘛？”
　　我很好奇，长到多年短则几个月的产品项目，竟然除了原型图之外没有任何的内容沉淀？！文件撰写与否和敏捷开发可能一点关系也没有，敏捷开发强调“适应性而非预见性”，并没有任何强硬的规定。
　　但是还有一句“可用的软件重于详尽的文件”，什么意思呢，就是告诉你文件不是不写，只是文档的形式不一样而已。从需求分析、业务建模、技术架构设计、再到样板代码都是需要有产出的，而且始终让关键角色人参与进来做决策、做验收、提反馈。
　　只要能够方便查阅设计资料组织形式和范围根据价值决定，只是说能正常怎么使用软件最重要，并不是文档类的资料因为比软件次要就不做了。整理文档类是需要的只是形式根据团队投入产出比选择最合适的那种方式整理，比较不是都有事都去看代码的。

　　敏捷好，其他方法不好
　　有些人一提到敏捷就大呼好，只要是敏捷的实践就什么都好，而提到CMMI等方法就大呼不好，不管是什么只要沾上边就哪里都不好，似乎敏捷和其他方法是完全对立的。
　　敏捷同样也吸取了其他方法论的优点，敏捷依然保持了很多历史悠久的实践和原则，选择一个方法或过程，并不是根据它是否敏捷，而应根据它是否适合。而要了解一个东西是否适合，还是要尝试之后才知道，任何没有经过实践检验的东西都不可信。
　　在这里可以看一下胥康、吴刚先生的论文期刊《敏捷模式下的软件项目管理方法研究》、《基于敏捷模式软件质量管理过程的改进方法研究》。《敏捷宣言》自2001年发表已经度过了二十余年时间，在这个多元化时代，各种各样的模式都在进行改进优化，有兴趣的可以在期刊中去查阅，找到更适合自己的改进方向。

　　了解测试管理面临的问题及角色
　　测试管理工作
　　1、测试工作流程的搭建、完善，涉及部门的相关公司体制；
　　2、测试项目的裁决和资源分配，资源的分配，包括人力资源和一些软硬件资源；
　　3、如公司无单独的质量管理团队，那么相对测试经理需要做QA的角色；
　　4、最后也是比较重要的一点，就是负责和各部门间的管理协调和沟通工作。
　　难以搭建的测试体系
　　软件测试算是国内近些年兴起的行业，ISO9000家族、CMM等体系也明确了工程团队中软件质量管理的必要性，软考等级中也纳入了评测师中级职称，种种情况都体现着测试行业的专业性和重要性。
　　但是中国软件企业在软件测试方面与国际水准仍存在较大差距，且每一个公司都有自己的见解：
　　1、在认识上重开发、轻测试，没有认识到软件项目的如期完成不仅取决于开发人员，更取决于测试人员；
　　2、在管理上随意、简单，没有建立有效、规范的软件测试管理体系；
　　3、缺少自动化工具的支持，大多数企业在软件测试时并没有采用软件测试管理系统。所以对国内软件企业来说，不仅要提高对软件测试的认识，同时要建立起完善的软件测试管理体系，让软件测试走向规范。

　　测试管理需解决的问题
　　测试关联度复杂
　　系统规模越来越大、集中度高、架构复杂、耦合度增强，使得业务和技术复杂度越来越高，测试设计和测试实施难度大，系统质量保障压力持续加大。
　　测试周期越来越短
　　业务需求提出到实现的周期越来越短，预留给测试的时间越来越短。面对复杂系统测试，如何压缩测试周期，提升测试效率，对测试部门管理能力和实施效率要求越来越高。
　　测试组织与协同难
　　测试规模越来越大、关联性越来越强，使得测试组织和协调难度大，特别是测试外包引入后，如何有效管控，保持“大而不乱”地高效、高质量地推动测试进程，确保测试项目成功。
　　测试人员成就感低
　　测试人员临时抽调，团队临时组建，无归属感成就感差，测试团队压力大，整天忙碌但成效差。
　　测试质量标准难统一
　　各部门、各角色对测试标准的理解不一致，操作流程和方法运用也各不同，测试交付质量不稳定，测试交付风险依然不可控。

　　根据质量控制测试管理需肩负的角色
　　质量卫士
　　对整体软件系统的质量负责，这个是测试人员的基本角色。但质量不仅仅是没有bug，还包含良好的用户体验，系统稳定性、良好的性能等。

　　流程推动者
　　一个强大的企业或团队一定有一个经过历练和不断优化形成的流程。同样构建一个良好的软件系统同样需要有一个高效的流程作为保障。
　　软件质量保障工作贯穿于整体软件生命周期中的每一个环节。所以测试人员就肩负起高效流程的构建及推动者的角色。

　　质量文化布道者
　　质量对于测试人员来说，是分内的事，但只有测试人员重视质量是远远不够的。
　　一个优秀的产品，需要每个阶段的参与人员都要对其质量负责，这就要求测试人员肩负起这一角色，将质量观念传播给项目中的各个参与者，使质量文化深入产品、开发、测试，让大家都有“质量”意识，共同为构建高质量的软件产品而努力。