关于持续交付:微软的软件测试之道作者Alan-Page-谈持续测试-IDCF

34次阅读

共计 3266 个字符,预计需要花费 9 分钟才能阅读完成。

当谈到采纳“继续测试”办法时,所有都与良好的设计无关。测试不再是开发的预先想法(afterthought)。“先写代码再做测试(write-first-test-later)”的心态曾经过期了。为了在您的组织内实现高质量和继续的测试,您在编写代码时必须采纳“测试优先(test-first)”的思维形式。

为了更好地了解组织在继续测试方面所经验的技术和文化转变,最近咱们(DZone)采访了 Alan Page (《微软的软件测试之道》作者、行业专家、微软前工程总监和现任 Unity Technologies 总监,@alanpage / angryweasel.com),就继续测试(Continuous Testing,CT)进行了交换,探讨了测试驱动开发的重要性、继续测试常见问题、继续测试的准则、以及 AI/ML 利用于测试的将来等。

Alan 对开发者的倡议:

  • 测试优先的心态。一旦开发人员在编写代码时开始思考测试,他们就会偏向于编写更易于测试的代码。
  • 延聘测试专家。不要让测试人员进行测试,而要雇用可能在开发团队中领导并影响测试文化的测试专家(编者注:相当于测试教练,和我之前说的 Test Owner)。
  • 100% 的测试可自动化。这是最大的测试设计挑战: 弄清楚要自动化什么。在 UI 测试之外,绝大多数测试(编者注:特地是单元测试、集成测试)都能够自动化。
  • 防止不稳固的测试。这些测试提供不统一或意外的测试后果。
  • 放弃简略。“如果很难进行测试,那么很可能代码不具备可测试性,这才是真正的破绽。”建设软件品质责任。明确开发人员的职责和责任,容许团队利用继续改良和继续测试准则,这样测试文化就会随着工夫的推移而改良。

1、团队实现继续测试(CT)的次要挑战之一是组织外部的技能和人才短缺。您将如何领导团队解决围绕测试的人才短缺问题?

Alan:在我职业生涯的过来六七年里,我所做的就是遣散测试团队。不是因为我不喜爱测试员——我已经是一名职业测试员。我发现,特地是在继续交付的团队中(通常是服务组织),在没有专用测试人员的瓶颈的状况下,软件研发更加高效。但我所做的不是打消(测试人员)而是合成和缩小(测试人员)。我的团队中通常有一些十分优良的测试员,但他们的工作并不是测试,而是为了帮忙开发人员更好地进行测试。

咱们须要解决测试专业化有余的问题,须要在团队的通才中造就测试技能,因而,在我工作的团队中,开发人员要对他们本人的品质和至多 90%~95% 的测试负责,同时还要对项目管理和交付的其余方面负责。

因而,我的办法是依附开发人员扩大他们的测试技能,并在一些测试专家的帮忙下进行大量的测试。

2、另一个常见的挑战是确定哪些测试要自动化,哪些测试要放弃手动。您的测试自动化的办法是什么,以及决定何时进行手动测试的办法是什么?

Alan:我至多在 10 年前就开始说,应该将“应该自动化的测试”100% 自动化。这里的逻辑解决测试设计的挑战:找出什么应该被自动化。例如,UI 测试不须要做到 100%,通常来说,在 UI 级别和 web 级别上更难以自动化的。

我通常倡议团队尽可能少地进行手工测试。为了做到这一点,在开发软件时,测试就是软件设计的一个选项,以一种易于应用自动化工具测试的形式创立软件架构。如果软件设计的形式是只能通过手工测试来实现大量的验证,那么咱们可能会陷入极大的窘境。

设计好软件系统,以便它的绝大多数能够通过低级测试(单元测试)进行验证。此外,对于必须手动测试的事件,还须要适当地进行一些检查和均衡,以便可能疾速和轻松地实现测试。我所留神到的,以及我当初教给成千上万的开发人员的,是如何进行良好的测试,一旦开发人员在编写代码时开始思考测试,他们就会偏向于使其所编写代码更具可测试性。

3、咱们发现,“测试文化的变动”被证实是组织的次要阻碍。对于团队如何克服这些文化阻碍,有什么倡议吗?

Alan:归根结底,作为一名开发人员,须要明确本人的职责和任务。我喜爱用团队中为数不多的测试专家来参加研发,目标就是是让他们在团队的品质和测试文化中表演重要角色。
咱们能够帮忙推动或驱动这件事,但我和我的开发主管一起做的一件事是:确保每一个开发人员深知他们要对软件的品质和交付负责。我会让公司里有这种特长的人来推动这种文化,而后咱们就尝试并进行继续的改良、继续的实际验证,基于这样的准则,测试文化应该始终变得越来越好。

但咱们必须对人们领有品质的各个方面有一个冀望和责任,这样能力开始建设一种文化,就像其余任何企业文化一样,你要激励那些你想看到的行为。在这样做的过程中,我积攒了一些能源,在整个组织中发明了一种共享的文化。

4、依据您在自动化测试和继续测试方面的教训,您看到过的团队所犯的最大谬误是什么?

Alan:

  • 试图在 UI 级别实现过多的自动化。这在明天依然是一个问题——尤其是在 web 空间。我晓得一些次要的应用程序是在 web 级别齐全应用 Selenium 进行测试的; 只是效率低下。这些测试须要很长时间; 它们是片状; 团队总是花工夫调试坏掉的测试。这是个很容易掉进的陷阱。
  • 测试不稳固。五、六年前,我加入了一个测试自动化会议,仿佛每个演讲都提到了不稳固测试的概念——运行中的测试会给您带来不统一或意外的后果。
  • 测试代码试图过于聪慧。如果很难使测试脚本失常运行,那么很可能是代码不具备可测试行,人们喜爱尝试测试脚本中玩一些小动作,这才是真正的 Bug。在编写测试时,为了测试而编写简单或难以解决的代码,您可能曾经发现了真正的 Bug:这些代码永远不会被保护。重要的是要留神相似的状况,不要为了测试脚本能运行而全力以赴。

5、令人诧异的是,十分小比例的受访者 (只有 8%) 示意,他们目前正在应用 AI(人工智能)或 ML(机器学习)进行 CT,回归测试和用户测试用例是次要的局部。在测试中,你认为团队应该在哪里扩大 AI/ ML 实现?

Alan:据我所知,所有应用 AI 和 ML 技术的测试工具都在(我之前埋怨过的)UI 测试畛域表现出色。导致传统的 UI 自动化测试不稳固的起因是 UI 能够挪动、id 能够扭转,所有的货色都能够扭转,毁坏你的测试。

在将来的五年里,咱们能够应用 AI 或 ML 为咱们生成大量的测试用例。更进一步,如果你能收集理论的客户应用模式——许多公司收集客户如何应用软件的数据——而后将这些数据输出 AI/ML 模型中来创立变异,就能产生额定的测试用例或测试运行。测试人员痴迷于端到端用户体验测试,比方这个用户工作流是如何工作的,这些测试往往是不稳固的。

然而,如果咱们可能解脱这些新工具中的软弱,联合 AI/ML 的能力,基于客户数据生成实在场景的测试用例,咱们就能失去一些十分有价值的货色。最初,如果我的疯狂打算停顿顺利,测试人员就不会花任何工夫或很少工夫来编写这些 UI 测试,而编写测试用例占用了太多的工夫,最初咱们就能失去了更高质量的产品。这就是我心愿的 AI 和 ML 方向。

6、在接下来的 6 -12 个月里,你会在哪持续进行测试? 你认为对于团队、开发者和管理者来说,为了获得成功,什么是最重要的?

Alan:继续测试、继续集成、继续一切都是对于增强反馈循环。继续部署就是要确保咱们能尽快失去对于咱们所构建的货色的反馈。

继续测试确保了咱们所做的每一步都是正确的测试。为了交付任何货色,无论是 CI 还是客户,无论在哪里,还有很多须要改良的中央。

尽管听起来很现实,但咱们还没到那一步。然而,一直地抉择正确的测试,在正确的工夫运行,不论这些测试是手动的还是主动的,并且减速整个零碎的品质反馈,将加强咱们在所有阶段取得反馈的能力,交付也越来越快。

起源:软件品质报道

作者:DZone

申明:文章取得作者受权在 IDCF 社区公众号(devopshub)转发。优质内容共享给思否平台的技术伙伴,如原作者有其余思考请分割小编删除,致谢。

5 月每周四晚 8 点,【冬哥有话说】品质与测试专场。公众号留言“品质”可获取地址

  • 0506 朱少民《如何最大化软件测试效力》
  • 0513 陈琦《数据驱动测试》
  • 0520 陈霁《没错,去 QA 是提高质量最无效的办法!》
  • 0527 施慧斌《DevOps 实际之继续测试》
正文完
 0