美文网首页PM@IT·互联网程序员
变革中的软件测试——组织篇

变革中的软件测试——组织篇

作者: 点融黑帮 | 来源:发表于2017-05-22 12:20 被阅读139次

    如果我们以Bill Hetzel提出软件工程的概念作为软件测试正式诞生的标志,那么软件测试发展到今天已经四十余年了。在长久的发展过程中,软件测试与软件开发的技术脱节越来越明显,渐渐的形成以人力密集型执行为主流的局面。这不仅使测试工程师的职业发展受到阻碍,更影响到软件测试的效率,有效性以及灵活性。

    如今越来越多的公司,尤其是互联网公司开始摒弃传统的劳动密集型测试,关注测试人员转型,将测试与开发的职责整合。想想几年前绝大多数公司还坚持着测试与开发分离的观点,不禁令人想起一句名言——天下大势,分久必合,合久必分。对于软件测试而言,这是一个变革的时代!

    变革的目的是提升测试效率,减少纯手动测试人力投入,重建与软件开发规律匹配的软件测试,提升软件测试的覆盖与效率。

    变革所需要解决的问题主要有:

    1.如何重构软件测试的组织形式?

    2.如何打造一支符合要求的软件测试团队?

    3.如何建立自动化的高效平台与框架?

    要解决的首要问题是如何重构软件测试的组织形式,因为这是一个战略性的规划,是保证软件测试顺利开展与执行的前提与基础。本文基于点融的实践,参考Google等业内公司的分享,对重构软件测试的组织形式进行再思考。

    全员测试的意识

    在软件测试漫长的发展过程中,渐渐形成了测试与开发泾渭分明的结构。开发工程师本能的依靠测试工程师完成软件质量的检测,这种职责的分割导致开发工程师质量意识相对淡薄,并且理所当然的认为测试应该由专门的团队完成。因此,我们要构建新的测试体系,就必须打破这样的意识认知。

    软件测试的本质是种职责,本身就是软件开发中不能被割裂的一部分,不应该被团队的组织架构所限制。所以,开发工程师也应该是测试的执行者。我们欣喜的看到,在很多公司这个观念已经得到良好的执行。如果我们更进一步,将这个思路扩展到整个产品研发体系,那么产品经理,开发工程师,测试工程师,UI/UX工程师,甚至于用户都应该投身于测试中。这样全员测试的方式将是我们构建新测试体系的基础。

    全员测试的意识,并不是一朝一夕可以建立起来的。在意识建立的过程中,必要的规范,制度以及评估方式作为配套体系必不可少。质量管理团队,测试团队,测试工程师等在此过程中,应当承担起指导者的作用。

    以测试工程师为中枢的项目测试组织

    当众多角色参与到测试中来,测试工作如何管理?这就需要测试工程师发挥作用了。在这个体系中,测试工程师的不仅仅进行测试用例设计和执行,他们将是测试策略的制订者,测试活动的规划者,测试过程的管理者,测试结果的验收者。

    请注意:测试结果的验收不等同于验收测试。测试结果验收是指对测试结果进行评审验收,关注于测试结果的完整性及结论。

    结合这个思路,我们可以定义出产品团队或者一个项目团队软件参与角色的基本职责。核心思想是将功能测试执行工作分散到不同的角色,由测试工程师进行协调跟进,因此项目团队中测试工程师人数不必多,以目前的实践经验,测试工程师与开发工程师的比例做到1:10是没有问题的,这样大大减少了专职手动测试人员的数量。

    对于系统级的专项测试,例如性能测试,压力测试等,仍然由项目测试工程师负责。如果在企业内部已经建立测试中心并提供专项测试服务,那么项目测试工程师负责向中心提交测试请求并跟进测试结果。

    参与测试的用户有几种情况:预发布阶段的内测用户,灰度发布时的真实用户,云服务商提供的众测资源,执行验收测试的业务用户,执行用户体验测试的选定用户。参与产品测试的用户务必保证来自该产品研发团队之外。

    这里重点说明一下测试策略的意义。测试策略是要解决测什么,怎么测,以及如何评估测试结果这三个问题。测试策略是所有测试活动的灵魂和核心,对于待测系统,其价值类似于隆中对之于刘备,农村包围城市之于中国革命。遗憾的是尽管有很多业内人士在不断呐喊,但对于测试策略的重视程度仍然远远不足。测试策略需要很强的专业领域知识与测试经验,是测试工程师的重要价值所在。

    对于功能测试,尽管分散到不同角色进行,但整个过程仍需在测试工程师的引导。可以将功能测试划分为两个级别:模块功能测试,系统功能测试,测试设计与用例仍然由测试工程师提供。

    功能测试级别

    执行角色

    说明

    模块功能测试

    开发工程师

    开发工程师的功能测试仍然信赖于测试用例,测试用例的提供仍然是测试工程师的职责

    系统功能测试

    测试工程师

    云测服务商

    用户如果与云测服务商合作,可以提供用例由其众测人员开展系统功能测试。

    在产品正式发布上线前,组织一定数量的用户进行内部测试是有效手段。

    这些职责并不是不可调整的,例如对于接口测试,测试工程师当然也可以参与进去,又如测试工程师提供测试策略,取决于测试工程师的技能与经验,也可以由测试工程师协调团队共同完成,或者由产品团队外的测试中心团队完成。

    下面让我们用一副图来说明软件测试各角色的协作关系:

    图中的测试中心将在后文中有详细说明。明显的,测试工程师成为软件测试的枢纽,指导测试过程,协调不同角色开展测试,对测试结果进行汇总审核。

    对于UAT和发布前的用户内测,一般建议对于内部To B系统邀请业务方进行UAT,To C系统邀请真实用户进行发布前内测。

    通常UAT及发布前内测的协调组织是产品经理的职责,因为产品经理始终面对用户,是最合适的人选。用户体验测试由UI/UX团队进行组织的原因在于,UI/UX团队的专业能力能够使用户体验测试的效果能够得到最大程度保证。而测试工程师需要在整个过程中提供技术及流程方面的指导。

    中心化与分散化

    在上一章节中说明的是一个产品,或者一个项目内的测试组织。这是测试工程师的分散化运作。仅凭这样的组织形式,还有很多问题无法解决,例如:通用的测试框架与工具,指导各项目的测试工程师,实践经验的全局化分享与改进等等。

    在项目管理中,往往通过PMO来对各项目进行规范,协调和指导,让我们借鉴项目管理与PMO的方法,引入测试中心这个概念。测试中心的职责在于:

    1.为各项目的测试工作提供规范及指导

    为了使测试工作能够在统一的标准下开展,需要由测试中心提供规范和流程指引。与此同时,测试中心根据各项目测试工程师反馈的数据进行分析统计,从了解全局测试情况,及时纠正或者改进测试工作。

    测试中心拥有资深的测试专业人士,对于测试方法,开发技术,软件架构,工具,业务等均有足够的经验,这使之可以成为一个指导或求助的平台,前面提到的测试策略就是一个例子。

    2.接收各项目的测试平台或测试框架需求,部署统一的开发,并提供统一测试服务。

    如果我们想减少劳动密集型的测试工作,提升测试效率,自动化的平台和框架是必须的。各项目情况各异,需要有统一的抽象与整合。对于有价值的技术建设成果,需要进行有效推广。此类技术性工作将是测试中心的重点工作之一。

    对于一些专项测试,例如性能测试,压力测试等,测试中心可以提供统一的工具,环境,技术等支持,甚至可以由测试中心完成通用的测试。

    另一方面,对于测试中心而言,需要收集各个项目的需求,了解其实践,以产品化的思维去规划真正能够用于提升测试覆盖及效率的自动化产品。

    3.协调测试资源,包括人力,硬件,环境等。

    项目测试工程师的委派,测试工程师的人力协调,测试框架和工具的开发或选型,外部服务(例如云测)等,如果由各项目独立进行则会引发很多混乱。因此,测试中心需要承担起这部分职责。

    测试中心的构成

    如果要使测试中心发挥实际作用,那么在测试中心内部可以建立四个团队:

    1.测试架构

    类似于开发架构师的作用,测试架构师是资深的测试专家,熟悉专业领域知识,了解开发技术,能够对测试对象进行策略及框架等全方位的指导。

    技术选型,工具选型,外部合作商评估等,也是测试架构团队的职责。

    2.标准化团队

    制订测试规范,统一模板,流程,评估标准等。通过对项目测试工程师反馈的数据进行分析,提供全局的测试状态,并不断进行改进。

    对于各项目实践经验的分享,框架及工具的推广等,也是标准化团队的工作内容。

    3.测试开发团队

    测试开发团队的主要职责是开发标准化的测试框架,以及旨在提升效率的测试工具。团队交付的框架工具,不仅服务于测试工程师,同时也可以服务于开发团队。

    测试开发团队由具备测试思想和经验,同时又兼具软件开发能力的技术人员组成。为了避免闭门造车,与实际需求脱节,测试开发团队有必要跟随项目进行开发工具,只有这样才能真正理解实际需求,提供有价值的交付。

    另一方面,框架和工具的开发,需要具备产品化的思维,由专门的人员用做产品的方式收集用户需求(来源于项目组,开发人员及项目测试工程师等),编写产品需求,并根据产品计划进行开发。

    在很多公司,已经取消软件测试工程师这一职位,取而代之的是测试开发工程师。但软件测试的不同目的决定了测试人员有不同的能力方向要求,至少在现阶段完全用测试开发工程师完全取代测试工程师的做法并不是完全有效的。关于这个话题,有机会我们另文讨论。

    4.统一测试服务

    软件测试中有一些通用的测试,如果各个项目各自建设,则重复造轮子,浪费人力物力。例如性能测试,可以提供一套标准化的环境,在此环境上实施测试。

    对于某些行之有效的测试框架,甚至于内部云测,均可以提供统一的测试服务,由测试中心的测试服务团队进行维护,大大减少重复建设的浪费,提升效率。

    此处讨论的是管理团队之外的执行团队,对于人力及软硬件资源的协调,无疑需要由测试中心的管理团队来完成。

    兵无常势,水无常形

    至此,本文已经完整阐明我们对软件测试组织方式的思考。与任何一种思想和理论一样,本文的观点也是基于对已知样本的再抽象,但具体到一个企业,一个公司,组织形式仍然需要因地制宜的分析,正所谓兵无常势,水无常形。

    例如,测试框架建设或者工具建设的工作,条件允许的情况下由开发工程师完成也未尝不可。再以测试开发团队为例,是一个由各不同项目的测试工程师构成的虚拟团队,还是一个专职的团队,也是可以根据实际情况调整的。

    又如,是建立公司级统一的测试中心,还是建立产品线维度的测试中心,又或者建立统一标准化团队+多中心的组织,也是因公司实际情况进行的不同选择。

    后记

    任何一种组织形式的确立,既取决于公司的决心,又取决于执行与实践。即使我们确立了满足当前需要的组织形式,也不断需要进行改进与调整,从这个意义上来讲,最优化的组织形式始终处于探索中,我们始终在路上。我们需要有知行合一的精神,不断思考,实践,再思考。

    面对大时代的变迁,面对软件测试的变革,我们期待与业界同仁一起努力,一起推动软件测试向更光明的方向发展。

    在暂时解决软件测试如何组织的问题之后,我们需要去解决新型的软件测试团队如何构建的问题,留待另文讨论。

    衷心感谢阅读本文的每一位朋友。

    本文作者:陈明(点融黑帮),现任职于点融网成都研发中心,长期从事软件测试,质量管理,项目管理等领域工作。

    相关文章

      网友评论

        本文标题:变革中的软件测试——组织篇

        本文链接:https://www.haomeiwen.com/subject/uzpbxxtx.html