Untitled

关于测试左移shift left的讨论已经持续了很长一段时间了,前几天刚好看到有外国友人亲身参与了这个过程,结果有点出人意料,所以翻译出来分享了一下。

在2017年,成为一名QA是一个有趣的时间。但不是搞笑哈哈,是有点点诡异了。每个人都想着测试左移(在合理范围内),但不是为了提高他们的质量,他们会以减少传统的质量保障人员的瓶颈的心态来做,那就是在迭代结束时,测试所有的东西。

我记得几年前,我是一个由5个开发人员组成的团队中唯一的QA,我们没有大量的自动化测试,但左移的思维方式得到了应用,至少是部分应用。我在开发人员做需求时,尽早地帮助他们,这在迭代结束后会得到回报,测试阶段的时间是最少的。充其量,我们会在测试阶段发现一两个问题,并迅速修复它们(或假设该问题到下一个版本)。

公司内部的一个新项目已经开始了,他们想在一开始就应用左移的思维方式,但他们不需要QA。所有的工作都可以通过自动化测试完成,开发人员将完全承担和拥有这些测试。作为一个QA人员,我很好奇,我想看看他们是怎么做的,他们是怎么涵盖这个用例的,或者其他用例的,我想学习并帮助他们。但是我被推到了一边,因为自动化才是王道,不需要 “手动QA”。

当他们在几个月后找到我的时候,我遇到了 “告诉你 “的时刻,他们在生产中出现了大量的问题。那是一个混乱的局面。这时他们意识到,即使他们写了大量的测试,他们也没有考虑到他们的测试策略。解决方案是在团队中加入一个 “手动QA”,来处理应用程序的问题,防止生产中出现更多的错误。

快到今天,我意识到他们已经非常接近了。他们拥有自动化测试策略。团队中的任何新开发人员都经历了严格的代码覆盖率、配对编程和细致的提交代码审核过程。他们唯一缺少的是一个好的测试策略,按照测试金字塔的描述进行工作(我知道你们中的一些人鄙视这个,但有时,它真的可以帮助团队分类并专注于正确的事情!),以及在用户体验上多想一点。

那么,你的QA团队成员可以在左移的转型或项目中扮演什么角色呢?

  • 在开始 “左移 “时,文档被证明是有用的。通过确保针对现有功能和新功能中最关键的点,它可以更容易地从传统的方法过渡。通常把重点放在用户的关键功能和你的应用程序中常见的脆弱点上。
  • 参加研发的启动会议。帮助提前考虑潜在的问题,用例子来引导这些会议是最好的做法。就我个人而言,我更喜欢在开发人员开始一个需求时以非正式的方式召开这些会议,但你也可以把这些会议变成一个定期会议,类似于你的scrum计划和复盘会议。这种做法也被称为3 amigos(读起来不错)。
  • 学会阅读代码,看看PR评论,学习自动化,你的QA团队成员越是多才多艺,开发人员就越有信心作为一个团队来交付他们的功能,而不是依赖一个QA警察。

如果你的团队没有一个已经在职的QA,你的团队已经可以开始应用同样的准则。停下来,呼吸,花15分钟思考可能的测试用例。不要在功能上走得太深,但思考所有可能的用户行为有很大的帮助。把它们写下来👏。这将帮助你防止很多 “我没有想到的 “情况。

虽然这不是一个完美的指南,但这是很好的第一步,我称之为 “在3天周末前的星期五下午4点部署的信心”。但这是另一个故事了。