很少看到有人讨论预发布环境的问题。今天正好看到一篇文章The Importance Of Testing In A Reliable Staging Environment，里面提到了一个很有意思概念反质量文化。个人认为文中讨论的预发布环境可能更接近于国内认知中的测试环境和预发布环境的结合体。尽管如此，文章还是非常有借鉴意义的，随便用 ai 翻译了一下，供大家参考。
许多软件开发组织会选择容忍缺陷丛生的预发布环境:很少有人认为这是个大问题。如果你从事软件开发,那么你很可能见过类似普通人的第一辆车那样状态的预发布环境。我们大多数人承诺在最初买下车辆时会修复问题,但实际上车辆保持的状态跟买来时一模一样!车门镜碎了,尾灯闪烁不定,勉强还能开。我们说服自己这些小问题不重要,也太贵了不值得修复。
我想精确地解释为什么这些“小”问题会给你的工程团队带来重大问题。事实上,它们很可能已经造成麻烦了。然后,我将给你一些建议,如何说服你的公司投入一些资源从根本上解决这些问题。最后,我将为你提供一些想法,以确保你成功完成清理预发布环境的任务——并保持其清洁!
预发布环境:一些基本事实和现实
当我谈到“预发布环境”时,这意味着任何工程师被期望用来执行其日常职责的开发或测试环境。这包括开发新特性、回归测试、运行自动化测试等。你的公司可能使用不同的术语。
质量低下、不可靠的预发布环境以及对生产环境的糟糕复制会向你的软件开发生命周期中引入细微的缺陷。它们很可能会被你的开发团队遇到,可能有人会在回顾会上提出几次。但从未采取行动解决它们。你有更高的优先事项;也许知道如何解决问题的人不再为公司工作了。无论如何,总有某种原因导致现在无法处理它。毕竟,它并没有阻塞任何人。然后,使用预发布环境的这种环境缺陷就被接受为一个事实。
“嘿,伙计们,我注意到这个页面在我们的预发布环境中无法加载……但这在生产环境中却不会发生。我们知道这是为什么吗?🤔”
“哦,天呐,它就是这样的 😂 别担心!”
这就是反质量文化开始渗入你的流程和团队心态的地方。
这将造成三个问题:
- 反质量文化
- 更高的生产问题风险
- 你的开发流程中的隐藏成本
反质量文化
什么是反质量文化?
反质量文化是团队范围内对低质量工作方式的接受。
如果说质量文化是为了质量本身而努力,那么反质量文化就是其反面。你的团队会慢慢对预发布环境中的意外行为变得麻木。他们开始假定(或怀疑)所有出现的意外行为都是由于环境被忽略而不是真正的问题引起的。工程师已经习惯了看到这些问题,学会了规避它们,结果也更加疏忽大意。这是一种反质量文化,直接导致缺陷疲劳。当我们习惯看到缺陷时,缺陷疲劳就会发生,我们会 develop 认知偏见并认为不相关的缺陷是环境问题,并因此改变我们的行为,可能会带来负面结果。
在缺陷疲劳出现之前,优秀的工程师会勤奋地花时间调查这些问题。你可能会注意到这体现在团队聊天消息、会议投诉或回顾会议中的问题上。你的负责人或管理人员可能最初不认为它们足够重要到需要修复的程度。但不太明显的是,在团队将其归类为环境问题之前,调查这个问题所浪费的时间有多少。
考虑这些场景。它们现在可能正在你的工程部门发生:
- 一位工程师正在代码库的一个不熟悉的部分工作,当他们看到页面的一部分突然不像应该的那样加载时。他们想独立工作,并决定在麻烦别人之前自己调查这个问题。他们花了一个小时调试自己的代码,假定他们的更改导致了这个问题,然后代码突然又开始正常工作了。后来他们询问并发现这是一种他们不知道的间歇性问题。
- 一位工程师完成了一个变更的工作,在发送给 QA 之前,他们快速检查了这个分支。他们在这个领域很有经验,完全了解软件中的所有怪癖。他们注意到一些奇怪的 UI 缺陷,但很快就得出结论,不太可能是他们的更改导致的……因为环境一贯有缺陷。他们将任务发送给 QA,很快就被打回,因为 QA 确认这确实是一个真正的问题。
随着时间的推移,第一种情况下的工程师可能会厌倦调查这些环境缺陷,无论是有意识地还是无意识地。最终,第一种情况中勤奋的工程师会变成第二种情况中经验丰富但误解的工程师!
当你的工程师反复查 bug 或意外行为时,缺陷疲劳就会发生,他们会感到精神被掏空。过了一段时间后,重复的调查完全停止。如果很有可能只是在浪费时间,那么工程师需要有很强的自我意识和自我控制才能一遍又一遍地查这些缺陷。
现实情况是:我们大多数人没有时间调查环境缺陷,所以我们依赖这些快速的认知偏见来节省时间。这可能导致错误地总结它们是环境问题……或者错误地总结它们不是环境问题。
反质量文化如何影响 QA 工程师
反质量文化会导致 QA 工程师士气低落。他们字面上就是质量保证,如果他们周围都是缺陷并且需要规避工作,这会让工作变得非常困难,坦白地说,这是令人沮丧的。
缺陷疲劳也会影响 QA 工程师,在主要职责是查找缺陷的角色中,这是一种很危险的习惯。我将在下一节中进一步探讨这一点。
QA 工程师可能是预发布环境中最频繁的用户:这是我们运行自动化测试和执行探索性测试的地方。如果你的公司不投入时间确保 QA 能够在不断遇到环境问题的情况下履行其角色,他们可能会另谋高就。或者,在另一常见的情况下,你剩下的 QA 工程师的生产力较低,没有发挥他们的全部潜力,这确实很可惜。
更高的生产问题风险
如果你的预发布环境充满缺陷,在测试期间可能会发生以下情况。一个 QA 工程师可能会经常遇到一个小的环境缺陷。尽管这些缺陷很小,但它们确实会影响你的用户,虽然是间接的,如果这些环境缺陷的副作用影响了你的运营底线。
首先,工程师必须弄清楚这个缺陷是由于预发布环境存在问题,还是确实存在于代码中。这需要宝贵的时间。
或者,如果他们决定不调查疑似的环境问题,这可能会有后果。现实情况是:QA 并不总是正确的,这可以理解!如果一个 QA 工程师有一个截止期限,让他们感到压力,并遇到一个“可能”是环境问题的东西,他们很有可能允许更改继续前进,因为他们认为这不是一个真正的问题,或者他们已经那么疲劳,以至于没有将其注册为一个问题。 QA 工程师也不是万能的。
