发布在即!企业 AIGC 应用程度测评,3 步定制专属评估报告。抢首批测评权益>>> 了解详情
写点什么

个性化测试流程,不搞一刀切

作者:Bailey Hanna

  • 2022-11-25
    北京
  • 本文字数:4710 字

    阅读完需:约 15 分钟

个性化测试流程,不搞一刀切

软件行业里的人——尤其是从事测试工作的人——会经常被问到:“对于‘在这里插入公司名称’这样的测试,你们的测试过程是怎样的?”人们想知道你公司的流程是怎样的,要么是出于好奇,要么是为了找到与他们的技能相匹配的东西,要么是为了找到他们认为你可以通过改变“一件事”就能解决的问题。但如果答案是“视情况而定”呢?

 

软件行业中的许多组织已经陷入了一种状态——他们为整个组织和全部团队制定了统一的流程。在开发、测试、部署等方面都制定了具体的方法。但大多数情况下,流程中的每个“步骤”都有一个固定的流程。问题是,每个团队都是不一样的,那么为什么他们采用的流程要是一样的呢?

 

在这篇文章中,我们将探讨采用个性化的流程对于团队来说意味着什么。这些个性化流程是由团队正在做的工作的上下文和团队本身所形成的。采用不同的流程意味着什么?你能从中得到(或失去)什么?你如何知道它们是否适合你的团队?你从哪里开始转向个性化流程?在摆脱统一流程的同时,你如何让组织走向成功?这些都是我们将在接下来的内容中要回答的问题。

究竟什么是个性化的团队流程

 

个性化团队流程是指特定于团队上下文和需求的流程。每一个团队都是独一无二的,他们所做的工作不同,团队的成员也不同,他们有不同于组织中其他团队的上下文和技能。因此,强制每个团队都遵循同样的过程可能是有害的。

 

UI 团队与后端团队就是一个很好的例子。这两个团队有不同的需求和不同的预期结果,所以如果他们遵循相同的过程,很可能会导致不必要的消耗。UI 设计团队的流程中可能有设计师审查新 UI 组件的步骤,但后端团队经常会跳过这个步骤。后端团队可能对不同类型的攻击有安全测试需求,但这些需求永远不会适用于 UI 团队。让他们定义对自己有意义的流程,确保他们不会浪费时间,让他们可以专注于找到他们自己的问题,并针对他们的上下文改进他们的过程。

 

这些流程也需要具备随着时间的推移而不断演化的能力,也一点很重要。当项目的优先级发生了变化,或者组成团队的成员发生了变化,他们的流程可能也需要发生变化。团队应该具备控制流程的自主性,他们能够定期地检查它们,并做出必要的变更,确保不会出现减缓团队进度的差异或消耗。这样可以确保他们的效率不会随着时间的推移而降低。

 

关于个性化团队流程,有一点很重要,那就是它们不应该是完全独一无二的。在某些领域,团队之间总是会有重叠的部分。例如,每个团队在开发过程中都可能会有这样的情况:他们的代码需要由另一个团队成员进行评审。可能大多数公司都有这样的要求。所以,这将出现在每个团队的流程中,但这并不意味着团队就不应该有个性化的流程,这只是意味着团队需要一些更有利于保持组织一致性的共性。通过添加或移除非必需的部分不断地适应团队上下文,从而形成个性化的流程。

这种做法有什么风险

 

采用个性化团队流程最大的风险是缺乏组织一致性。例如,假设你有一个团队专注于自己的流程,他们尝试了一个“新”的测试框架,但不跟其他团队分享,那么有可能你的另一个团队在做着同样的事情,这等于付出了双倍的努力,但不分享任何关于搭建和运行这个框架的经验教训、挑战、提示和技巧等等。团队需要知道他们有能力选择最适合他们的流程,但不一定是全新的流程,这点很重要。他们可以向其他团队学习,利用已有的见解,引入已经被尝试和证明过的流程,这些流程可以帮助每个人,与自己的团队环境相契合。所以,如果没有这种一致性和共享个性化流程,很容易变得弊大于利。我们将在后面的部分进一步探讨降低这种风险的方法。

 

其他一些需要注意的风险包括——流程可能缺乏透明度、在转换流程时对团队造成混乱、增加了团队间移动的时间,以及跟踪审计需求上的困难。其中一些风险在有严格合同义务的公司中尤其普遍。对于缺少审计需求这样的事情,你可以确保它们始终出现在所有的流程中,类似于之前提到的代码评审流程。大多数其他的风险也与缺乏一致性有关,通过在团队之间建立共享信息和讨论的基础,你也可以很好地应对这些风险。尽管这增加了实施个性化流程所需的工作,但如果团队有决心,还是可以实现目标的。

个性化的团队流程有哪些好处

 

引入这些特定于上下文的流程将给团队带来的好处包括——提升效率(有利于组织和客户)和增加团队中个体贡献者的所有权感(有利于员工的满意度和成长)。

 

我们通常可以看到,通过让团队在日常的流程中拥有额外的所有权和发言权,开发的特性的质量得到了改善,效率得到了提升,满意度也得到了提升,因流程与需求不一致而产生的挫败感减少了,在工具和框架方面采用了创新的方法,因为他们可以更容易地在这些流程中探索,并增加了调整变化的灵活性。当然,真正的好处可能不止这些。这些是我在几乎每一个使用这种方法的团队中所看到的共同好处,有些团队还看到了他们自己的好处,如增加团队内部的沟通、更好地实现目标等等。

 

我个人认为,我看到的最大好处是减少了测试和质量保证过程中的摩擦。当测试和质量的需求与团队正在做的工作相适应时,他们就会对这些流程更加开放。他们可以理解我们采取这种方法背后的原因,这有助于事情更顺利地进行。当他们能够定义适合他们的测试流程时,整个团队对测试流程的态度发生了非常积极的转变。

怎么知道个性化团队流程是否适合自己的团队

 

确定个性化流程是不是正确的选择或是否适合你的团队,这是一个关键的步骤。无论它们听起来有多有趣,或者有多让人感到兴奋,在尝试转向个性化团队流程之前,都需要了解组织和团队的当前环境。所以,我将从一些潜在的不适合的指标开始讲。

 

我见过的个性化团队流程在组织中运行不好的一些明显的指标是:有严格的合同义务、有严格的瀑布流程、有非常紧密耦合的架构,以及团队之间的沟通已经存在问题。之所以说这些对于团队来说通常是最大的危险信号,是因为当你有更严格的流程和需求时,在团队转向个性化流程时会很容易错过一些东西。特别是当组织内部已经存在沟通问题时,团队可能不知道要在每个团队中保留流程的某些方面,他们可能会删除它们,从而导致大规模的后果。

 

根据政府法规处理医疗数据文件的公司就是这方面的一个很好的例子。出于隐私考虑,他们需要遵循非常严格的流程。具有紧密耦合架构的组织在团队无法保持流程一致时也会遇到问题,如果缺乏沟通,情况会变得更糟。为了让有这些情况的团队能够在个性化的团队流程中茁壮成长,团队之间需要有非常健康的沟通。

 

我们已经讨论了个性化流程可能不适用的情况,那么我们该如何知道它们何时是适用的呢?适用个性化流程的最佳指标是:拥有自主且高功能的团队、拥有或正在转向解耦的架构、拥有因无法尝试新流程或消耗而受挫的团队,以及一些已经开始这样做的团队。

 

我将从最后一点开始深入探讨。在很多情况下,团队已经在以某种方式这么做了。如果已经存在一个组织层面的流程,但其中某些方面不适用于团队,他们可能会让新员工跳过这些部分。或者你可能会经常听到他们谈论不适用于他们的东西。这意味着团队已经开始定义他们自己的流程,但还没有能力使其成为普遍的实践。他们已经在做他们需要做的事情,找出现有流程中的消耗或差距,并做出必要的改变,以便更好地满足他们的需求。这充分表明了他们可以从个性化流程中获得多大的好处。

向个性化的团队流程迈进

 

如果你已经被说服去尝试个性化团队流程,我强烈建议你循序渐进地朝着这个方向努力。试图立即让每个团队都开始定义他们自己的流程会导致更容易出现前面提到的一些风险。通过放慢脚步,你可以在朝着目标努力的过程中发现问题并解决它们。

 

第一步是定义当前的流程。确保一切都有良好的定义,当前的方法让团队能够识别那些流程中存在的差距,或者需要添加额外的流程来满足他们的需求。如果定义了组织层面的流程,团队需要对其进行评审,并添加任何必要的额外步骤,以弥合那些已确定的差距。在完成之后,团队应该与其他团队分享这些增加的内容,看看是否可以让其他团队也从中受益。

 

在团队适应了组织方法之后,他们就可以开始移除其中的某些部分了。他们可以再次检查当前的团队流程,但这一次要找出任何不满足需求或团队环境的步骤,并将它们从流程中移除。在团队确定了这些步骤之后,他们应该与其他团队分享这些改变,以便获得反馈,确保这些步骤不是团队不知道的某些合同义务所要求的。到了这个时候,团队就有了一个适合他们环境的个性化团队流程!

 

团队需要做的最后一步是开始定期检查这些流程。定期检查流程的差距和消耗,可以让它们随着团队的发展而演变。当需求和团队成员发生变化时,确保所有的东西都与团队环境保持一致。和往常一样,如果流程发生了变化,这些变化应该在团队之外分享。

 

到了这个时候,团队将开始真正采用个性化的团队流程。从这个时候开始,他们应该留意从这种方法中得到的好处,并确保定期与所有的团队一起检查流程,确保这种方法是有效的,并且所有团队仍然保持一致。

我们怎样才能取得成功

 

我们知道,缺乏一致性和内聚性是导致个性化流程不健康的最大风险,那么我们如何尽早应对风险并为成功做好准备?我通常会从这三方面入手——文档化、跟踪和实践社区。

 

拥有最新的、可理解的团队流程文档是非常重要的。文档可以让其他团队了解你的流程,还可以让你的团队验证所有人都在与所定义的流程保持一致。对于团队来说,定期访问这些文档,保持文档的新鲜度和准确是很重要的,当你修改了流程,需要共享更新,并确保其他团队也能访问到它们。

 

对其他团队来说,跟踪是一种很好的方式,可以让他们更好地了解你的流程以及它们是否适合他们的团队。在开发和测试过程中结对并相互跟踪,可以更好地了解这些流程是如何运作的,这有助于解决可能存在的本应记录在文档中的问题。

 

最后一点是要有实践社区。社区通常是一种开放的论坛,个人可以在这里围绕发起的主题展开讨论。我喜欢根据不同的角色把实践社区分成多个。例如,可能会有一个测试和质量实践社区,团队可以在这里分享关于这些主题的想法和信息。这里是团队理想的讨论流程(实践开发社区中的开发流程、实践质量社区中的测试流程,等等)的地方。他们建立了一个安全的空间来讨论胜利、挑战、技巧等,并让其他团队看到在其他团队中率先使用的新流程是否也适用于他们团队!

 

虽然你可以只使用其中的一种或两种方法,但我发现最好是一起使用。它们可以帮助个人在最适合他们的环境中学习。例如,有些人最好的学习方式是阅读,有些人最好的学习方式是一对一的对话,而有些人则喜欢在更大的群体中讨论这些话题。把这三者结合起来,你就为成功做好了最好的准备!

这一切意味着什么

 

总的来说,让团队采用由他们的工作和团队上下文定义的流程有很多好处。但是,就像生活和工作中的许多事情一样,它们也需要工作量。

 

让团队建立适合他们工作环境的实践可以增加团队的自主性,提升团队的效率和工作成果的质量。它可以让团队使用的流程和实践随着团队的发展而演化,团队可以在组织内进行试验,并与其他团队共享更多的内容。团队还将看到令人沮丧的消耗在减少,也不需要坚持对他们的日常工作来说没有意义的需求。通过让团队更多地控制他们采用的流程,团队、组织和客户都会从中受益。

 

作者简介:

Bailey Hanna 是 Auvik Networks 公司(位于安大略省滑铁卢市)的高级测试策略专家,她不仅在工作上表现出了她对软件质量的热情,还是技术大会的演讲者,以及 Kitchener-Waterloo 软件质量协会的董事会成员。她的主要兴趣和经验领域是上下文驱动的探索性测试、测试策略、风险分析以及完善或开发健壮的团队流程。她进入测试领域的经历让她学到了很多好的实践,当然也学到了不好的实践,她期待着有机会与他人分享这些经验。

 

原文链接

https://www.infoq.com/articles/individual-team-processes/

2022-11-25 09:514378

评论

发布
暂无评论
发现更多内容

计算机的时钟(三):向量时钟

ElvinYang

C语言指针详解

C语言与CPP编程

c c++ 编程语言 指针

金沙账号审核不通过维护不给提现风控怎么回事?怎么办

过山太阳

内容审核 提现不了

【高并发】面试官:讲讲什么是缓存穿透?击穿?雪崩?如何解决?

冰河

缓存 穿透 击穿 雪崩 签约计划第二季

记录问题 INSERT INTO table ... SELECT ... FROM dual WHERE not exists (...)问题

转山转水

sql SQL语法 sql查询

重新学习了一遍ThreadLocal

熊斌

学习

Go: 理解 Sync.Pool 的设计

陈思敏捷

sync sync.pool pool Go 语言

布式系统消息异常该何去何从

架构师修行之路

分布式 异步

第五周总结

Vincent

极客时间 极客大学

从一段 Dubbo 源码到 CPU 分支预测的一次探险之旅

yes

dubbo cpu

浮点数的秘密

C语言与CPP编程

c c++ 编程语言 浮点数

第五周作业

Vincent

极客时间 极客大学

以大数据为依托提升基层治理效能

CECBC

大数据 信息化管理

华为与第四范式,正在酝酿一个帮企业跳出AI悖论的“秘密计划”

脑极体

spark总结

纯纯

智能商业时代的思考(二)网络协同抓住用户

刘旭东

微信 商业价值 数据智能 网络协同 商业智能

区块链激励层——区块链生态建设的驱动力量

CECBC

区块链技术 驱动力量

安全相关总结

纯纯

区块链应用层——生态体系的上层建筑

CECBC

区块链技术 生态体系

架构师训练营第十四周总结

张明森

CString 类的线程不安全问题

C语言与CPP编程

c c++ 编程语言

洗牌算法

C语言与CPP编程

c c++ 算法 编程语言

SpringCloud轻松集成Dubbo实现RPC调用

Barry的异想世界

微服务 dubbo nacos RPC spring cloud alibaba

HashMap将cpu打满始末

hashmap 线程安全 cpu 100% cpu飙满

认证、授权、鉴权和权限控制

哈库拉玛塔塔

spring security 用户权限 鉴权 权限

不使用Raft算法,就能简单做集群leader选举

架构师修行之路

分布式 架构师

03 Spring Security 入门实例

哈库拉玛塔塔

Spring Boot kotlin spring security

Spring Security 主要类解释

哈库拉玛塔塔

springsecurity

一文带你了解微服务架构和设计(多图)

Phoenix

架构 分布式 微服务

ARTS Week16

时之虫

ARTS 打卡计划

导致系统不可用原因及密码验证

纯纯

个性化测试流程,不搞一刀切_文化 & 方法_InfoQ精选文章