很少看到有人讨论预发布环境的问题。今天正好看到一篇文章The Importance Of Testing In A Reliable Staging Environment，里面提到了一个很有意思概念反质量文化。个人认为文中讨论的预发布环境可能更接近于国内认知中的测试环境和预发布环境的结合体。尽管如此，文章还是非常有借鉴意义的，随便用ai翻译了一下，供大家参考。

许多软件开发组织会选择容忍缺陷丛生的预发布环境:很少有人认为这是个大问题。如果你从事软件开发,那么你很可能见过类似普通人的第一辆车那样状态的预发布环境。我们大多数人承诺在最初买下车辆时会修复问题,但实际上车辆保持的状态跟买来时一模一样!车门镜碎了,尾灯闪烁不定,勉强还能开。我们说服自己这些小问题不重要,也太贵了不值得修复。

我想精确地解释为什么这些“小”问题会给你的工程团队带来重大问题。事实上,它们很可能已经造成麻烦了。然后,我将给你一些建议,如何说服你的公司投入一些资源从根本上解决这些问题。最后,我将为你提供一些想法,以确保你成功完成清理预发布环境的任务——并保持其清洁!

预发布环境:一些基本事实和现实

当我谈到“预发布环境”时,这意味着任何工程师被期望用来执行其日常职责的开发或测试环境。这包括开发新特性、回归测试、运行自动化测试等。你的公司可能使用不同的术语。

质量低下、不可靠的预发布环境以及对生产环境的糟糕复制会向你的软件开发生命周期中引入细微的缺陷。它们很可能会被你的开发团队遇到,可能有人会在回顾会上提出几次。但从未采取行动解决它们。你有更高的优先事项;也许知道如何解决问题的人不再为公司工作了。无论如何,总有某种原因导致现在无法处理它。毕竟,它并没有阻塞任何人。然后,使用预发布环境的这种环境缺陷就被接受为一个事实。

“嘿,伙计们,我注意到这个页面在我们的预发布环境中无法加载……但这在生产环境中却不会发生。我们知道这是为什么吗?🤔” “哦,天呐,它就是这样的😂别担心!” 这就是反质量文化开始渗入你的流程和团队心态的地方。

这将造成三个问题:

  • 反质量文化
  • 更高的生产问题风险
  • 你的开发流程中的隐藏成本

反质量文化

什么是反质量文化?

反质量文化是团队范围内对低质量工作方式的接受。

如果说质量文化是为了质量本身而努力,那么反质量文化就是其反面。你的团队会慢慢对预发布环境中的意外行为变得麻木。他们开始假定(或怀疑)所有出现的意外行为都是由于环境被忽略而不是真正的问题引起的。工程师已经习惯了看到这些问题,学会了规避它们,结果也更加疏忽大意。这是一种反质量文化,直接导致缺陷疲劳。当我们习惯看到缺陷时,缺陷疲劳就会发生,我们会 develop认知偏见并认为不相关的缺陷是环境问题,并因此改变我们的行为,可能会带来负面结果。

在缺陷疲劳出现之前,优秀的工程师会勤奋地花时间调查这些问题。你可能会注意到这体现在团队聊天消息、会议投诉或回顾会议中的问题上。你的负责人或管理人员可能最初不认为它们足够重要到需要修复的程度。但不太明显的是,在团队将其归类为环境问题之前,调查这个问题所浪费的时间有多少。

考虑这些场景。它们现在可能正在你的工程部门发生:

  1. 一位工程师正在代码库的一个不熟悉的部分工作,当他们看到页面的一部分突然不像应该的那样加载时。他们想独立工作,并决定在麻烦别人之前自己调查这个问题。他们花了一个小时调试自己的代码,假定他们的更改导致了这个问题,然后代码突然又开始正常工作了。后来他们询问并发现这是一种他们不知道的间歇性问题。
  2. 一位工程师完成了一个变更的工作,在发送给QA之前,他们快速检查了这个分支。他们在这个领域很有经验,完全了解软件中的所有怪癖。他们注意到一些奇怪的UI缺陷,但很快就得出结论,不太可能是他们的更改导致的……因为环境一贯有缺陷。他们将任务发送给QA,很快就被打回,因为QA确认这确实是一个真正的问题。

随着时间的推移,第一种情况下的工程师可能会厌倦调查这些环境缺陷,无论是有意识地还是无意识地。最终,第一种情况中勤奋的工程师会变成第二种情况中经验丰富但误解的工程师!

当你的工程师反复查bug或意外行为时,缺陷疲劳就会发生,他们会感到精神被掏空。过了一段时间后,重复的调查完全停止。如果很有可能只是在浪费时间,那么工程师需要有很强的自我意识和自我控制才能一遍又一遍地查这些缺陷。

现实情况是:我们大多数人没有时间调查环境缺陷,所以我们依赖这些快速的认知偏见来节省时间。这可能导致错误地总结它们是环境问题……或者错误地总结它们不是环境问题。

反质量文化如何影响QA工程师

反质量文化会导致QA工程师士气低落。他们字面上就是质量保证,如果他们周围都是缺陷并且需要规避工作,这会让工作变得非常困难,坦白地说,这是令人沮丧的。

缺陷疲劳也会影响QA工程师,在主要职责是查找缺陷的角色中,这是一种很危险的习惯。我将在下一节中进一步探讨这一点。

QA工程师可能是预发布环境中最频繁的用户:这是我们运行自动化测试和执行探索性测试的地方。如果你的公司不投入时间确保QA能够在不断遇到环境问题的情况下履行其角色,他们可能会另谋高就。或者,在另一常见的情况下,你剩下的QA工程师的生产力较低,没有发挥他们的全部潜力,这确实很可惜。

更高的生产问题风险

如果你的预发布环境充满缺陷,在测试期间可能会发生以下情况。一个QA工程师可能会经常遇到一个小的环境缺陷。尽管这些缺陷很小,但它们确实会影响你的用户,虽然是间接的,如果这些环境缺陷的副作用影响了你的运营底线。

首先,工程师必须弄清楚这个缺陷是由于预发布环境存在问题,还是确实存在于代码中。这需要宝贵的时间。

或者,如果他们决定不调查疑似的环境问题,这可能会有后果。现实情况是:QA并不总是正确的,这可以理解!如果一个QA工程师有一个截止期限,让他们感到压力,并遇到一个“可能”是环境问题的东西,他们很有可能允许更改继续前进,因为他们认为这不是一个真正的问题,或者他们已经那么疲劳,以至于没有将其注册为一个问题。 QA工程师也不是万能的。

突然之间,那些微小的缺陷,或者与它们所在区域相关的缺陷,正在生产中出现,你的产品用户正在报告缺陷。如果你曾经在生产中看到过显然的缺陷,“应该”被发现,那么值得考虑环境问题是否遮蔽了真正的缺陷是一个促成因素。

问问自己:如果你的团队在预发布环境中存在缺陷,当产品代码真的出问题时,他们怎么知道呢?

你的开发流程中的隐藏成本

但是修复这些需要花这么多钱……

你的预发布环境中的缺陷已经在耗费你公司的资金。考虑一下每年运行该环境需要花费多少钱。这个成本是固定的,即使你的环境充满缺陷,它也不会改变。即使你的工程师发现它难以使用且对生产力有损,你的公司仍然要为环境支付完全相同的费用。

如果一个QA工程师经常花时间调查和确认这些问题是环境问题,那么这就是浪费时间。他们本可以用这段时间进行自动化、探索或质疑需求。相反,他们在调查一个你公司的其他工程师可能已经调查过上百次的问题。一个公司在员工集体调查微小缺陷上的花费超过修复它们所需的资金需要花多久?

如果每个QA工程师都要反复调试预发布环境,每个新的QA工程师都要反复提出同样问题区域的同样问题,这会影响他们的生产力。如果QA花几个小时调查测试失败是真实的还只是环境问题,而不是测试新特性,这也会影响他们的生产力。QA工程师的生产力对于为用户提供价值至关重要。QA通常是发布前的最后一步,如果他们的时间被环境缺陷浪费,这意味着用户得到新特性的速度更慢,从应用程序中获得的价值也更少。这并不像最坏的情况那么明显:你的产品客户发现缺陷并提交缺陷报告。

由于他们的执着,一些QA工程师通过根据具体情况使用不同的环境来保持高标准。如果他们在一个已知有问题的环境中测试一个区域,他们会在有机会的情况下使用另一个环境。这意味着你的公司花钱维护的这些环境的某些部分不可用,这非常浪费。

其次,工程师调查这些问题所花的额外时间(如果他们这样做)也会增加你公司的成本。最后,如果你的工程师不调查这些问题,很可能最终会出现生产问题。突然之间,如果一开始就解决了环境问题,这对你的公司的成本要高得多。

修复预发布环境是必须的。我该如何向公司推销这一点?

你的团队已经投票决定修复预发布环境了。非常好。但这项工作什么时候能完成,需要花费多少成本?你该如何确保一年后不会重蹈覆辙?

如果你在软件开发领域工作,那么你的产品路线图可能已经排满了未来五年的财政预算。仅仅挤出时间放假已经非常困难,把修复这些“低优先级”bug塞进你繁忙的sprint里就更加困难了。所以,如何向你的团队销售这一点是一个好问题:你将如何做到这一点?

让我们重申一下发现的问题。经常接受低质量的环境会造成一种反质量文化。这些低质量的环境使工程师更难高效工作,导致沮丧、士气低落和生产力下降。这可能导致员工流失。它甚至可能导致生产bug,让公司付出高昂的代价。

为了让你的管理者支持这一决定,并了解你的团队为什么应该花时间修复预发布环境,你需要一个计划。

这就是我们发挥创造力的地方,因为这个问题有很多答案!首先,如果你意识到一个反质量文化已经渗透到你的工程团队,首先要做的就是承认这是一个问题。利用前面提出的要点,你可以努力说服更广泛的团队,这些小的环境bug对你的软件开发生命周期有广泛的连锁反应。鼓励团队注意环境问题,不要像往常一样接受它们,而是给他们一个机会,像记录生产bug一样开始编录这些问题。(如果你还没有这样做,请尽快开始记录生产bug!)

在认识到问题之后,了解存在哪些bug以及它们出现在哪里是必要的,这样你就可以对问题的规模有一个概念。这将指导你的下一步,也就是选择处理它们的最佳方法。

修复环境bug的最佳方法将根据你的具体情况有很大差异。一些想法:

组织一次黑客马拉松比赛,多个团队相互竞争修复最多的环境bug

以小批量的方式,随时间推移将环境bug修复工作单流入每个sprint,以避免对常规sprint工作的破坏

在sprint回顾和计划之间的空档期修复环境bug。只要在每个sprint中引入即使是一个环境bug修复点,那也是一个进步,总比没有好。

我再次鼓励你让你的团队对此感到责任重大。如果你能设定一个目标,在y个sprint内修复x%的环境bug,并在连续的几个sprint中实现这个目标,这将有助于巩固修复这些bug作为一个重要项目的理念。你可以在sprint仪式、技术路线图会议或者定期的其他工程uddle或全体碰头中监控这个目标。开始谈论它!

一些最后的建议

我建议像对待优先利益相关者一样对待你的工程师,并就环境bug制定某些服务级别协议。确保环境bug以及你实施的任何相关流程得到沟通和记录。如果做得好,这将使你的团队能够在bug出现时及时处理。

当然,这说起来容易做起来难。刚开始时,你可能是唯一认为你的工程团队应该花时间做这件事的人。我相信通过说服、展示热情和利用这篇文章中的要点,你应该能够说服其他人持同样看法。

如果你认为环境bug是一个问题,这表明你本能地渴望事情变得更好,这是值得自豪的!你认识到细小的问题会积累成为你和你团队的大问题。帮助别人看到同样的事情并采取行动。