我如何让管理层相信我们需要一个正式的 QA 部门?

软件测试 管理
2022-01-17 16:29:00

在我的公司,我们并没有真正的 QA 部门。如果您已经关注了我的一些其他 问题,那么您基本上就知道了,我们没有自动化测试,我们的“测试人员”是设计项目的分析师。

当我最近提出建立一个更正式的(我实际上使用了“行业标准”这个词)质量保证部门的想法时,我被告知“决定采用精益开发流程。” 原来这个决定是在大约 7 或 8 年前做出的。仅在过去 5 个月中,我才说服他们进入 2 周的部署周期(之前是 3-4 个月),并且仅在上个月,他们才削减了供“测试人员”进行测试的“构建”。此外,对该“构建”进行任何必要的更改(代码能够被编译或解释,因此修改很容易。)“构建”在引号中的原因是因为它实际上只是主干的副本,最多最近的更改在路径中处于较高位置,因此它们会首先被找到,并且这一切都会在运行中得到解释。

所以,似乎对什么是“精益开发”存在根本性的误解。他们过去有一个 QA 部门,但因缺乏生产力而烦恼。当然,我们知道 QA 部门并不“高效”。如果您从制造的角度来看(他们确实如此),从定义上讲,质量保证会通过增加失败和延长项目的机会来阻碍生产力。(我们尝试使用这样的论点,即软件的 QA 就像他们制造的产品的 QA。他们不这么认为,因为政府对他们的 QA 有要求,但对软件没有要求。)

我如何让他们相信正式的 QA 将使公司受益?

4个回答

这一定是开发人员在没有 QA 的公司中面临的最常见情况之一。由于我是 QA 专业人士,而不是开发人员,让我尝试从 QA 的角度来解释它。

首先,QA 生产力很难衡量。如何做到这一点并没有真正的行业标准,而且很可能是不可能的。但是,投资回报要容易一些。QA 只是人类,所以我们平均会漏掉 20% 的错误。现在想想您在软件投入生产时遇到的问题。每个软件故障都会花费金钱,花费时间修复它,停止生产,损失收入或其他地方。节省 80% 的钱总是有用的。

其次,在周期中越早发现错误,就越容易修复(阅读成本更低)。设计中的错误比代码中的错误更容易修复 10 倍,而代码中的错误比生产代码中的错误要容易得多。

第三,我发现适用于老式“真实行业”人士的比喻是人力资源或会计。他们的存在是为了促进业务的核心工作,即使他们不运行制造产品的机器。

除此之外,我想问别人是否会驾驶一辆装有未经测试的电机控制软件的汽车。该软件重要,否则您将不会这样做。

目前有多少开发人员时间花在维护活动上?熟练的 QA 不仅可以发现错误,还可以帮助提高代码和开发质量的其他方面,从而使开发人员经常从影响生产力的平凡的低级活动中解脱出来。结果可能是实际产量的巨大增长(不过,“熟练”这个词在这里很关键)。此外,拥有一个 QA 部门应该让您的公司更容易雇佣更好的开发人员并留住现有的开发人员,因为最好的开发人员将习惯于与 QA 合作。没有 QA 可能会给潜在的员工一种印象,即您的公司不是一家技术公司,并且不认真对待软件开发。

但老实说,我的印象是管理层可能只是不听你的。

你的直属上司呢?他的技术是否足以被说服?您的团队能否摆脱“变通”质量检查,您的一个开发人员需要四分之一左右的时间成为 SDET,并且团队轮流履行这一职责?这不如一个专注于职业生涯质量的专业测试人员,但可能比目前的情况更好。然后,您将有一个人专注于寻找产品可能一次失败 3 个月左右的方法,这比只让人们找到成功的方法然后投入一些努力来确保它不会失败是一个巨大的进步不会失败。如果开发人员是面向测试的,也许你可以说服管理层,在尝试了几个月后,永久地从 SDE 转移到 SDE-T 是有保证的。

你可以提出的最好的论点是找到一份更好的工作,然后跳槽,除非你现在的公司有一个真正的 QA 部门——或者干脆离开,告诉他们原因。“用脚投票”是员工的有效选择。当然,这取决于您对这个问题的感受有多强烈,以及在您的公司工作还有哪些其他利弊。我确实觉得贵公司不了解技术,但这并不意味着他们不成功或您的报酬很低。只要确保您保持足够的最新状态,以便将来过渡到一家技术更高的公司,不要让您的技能停滞不前!“管理不善导致职业生涯死亡”在科技界并非闻所未闻。

TL;DR:如果管理层没有倾听,您可以尝试通过让开发人员临时 SDET 或尝试将开发人员永久移动到 SDET 位置来解决它们。否则,您可能要考虑离开一家技术更精通的公司,并让他们知道原因。

使用事实和数据来支持您关于为什么需要 QA 部门的声明。你身边的一件事是你每两周发布一次。开始跟踪的一件事是每个版本发生的缺陷数量,以及如果您确实发现了错误,您必须部署多少其他版本/修复。

当您可以实际地解释更快的开发周期和更高的质量时,您的案例就会变得容易一些,但这仍然是一条艰难的道路。

我相信这里的中心问题是

  • “最终发布后用户发现了多少错误?”
  • “最终版本中的错误有多严重?”。

管理层似乎没有看到专门的 QA 的意义,因为他们在最终版本中没有看到很多严重的错误。揭露这些错误,显示基本的错误统计数据,进行最终用户满意度调查都有机会说服他们。