在敏捷开发环境中没有 QA 团队的测试

软件测试 手动测试 敏捷测试
2022-01-10 21:41:18

我目前在一个由几个开发人员组成的小团队中工作,但即使是一个由高效开发人员组成的小团队也可以在一次迭代中开发很多功能(在我们的例子中是 2 周)。我们没有 QA 团队,所以通常我们会在迭代的最后一两天对我们没有自动化测试的部分进行手动测试(我们也在编写自动化测试) ,但有些事情真的很难自动化)。

这有效地将我们的开发时间缩短到每次迭代大约 8 天。对于那些在这种环境中工作过的人,你能就你如何处理这个问题提供任何建议吗?您是否在迭代结束时增加了几天?您是否没有为测试分配额外的时间而只是开发直到迭代?我们的目标是始终拥有可部署的软件(尤其是在迭代结束时),因此这些测试日似乎是必须的。

4个回答

我以前是团队中的第一个测试员,并且看到他们之前是如何测试他们的软件的(通常也做得很好)。尽管你很小,但我认为你大部分时间都在正确的轨道上。

随时随地创建自动化测试非常棒。您可能会发现一些 TDD 方法有一些好处,这些方法要求您在编写代码之前创建测试。绝对可以使测试更容易编写。

与其让每个人在迭代结束时花一两天时间,不如让一个(轮换的)开发人员在整个迭代过程中定期花时间测试软件怎么样。这肯定会减少你的反馈循环。在这种情况下,您可能只需要在迭代测试结束时花费 1 天时间。

我知道很多人反对这个想法,但我看到一些小团队会一次又一次地进行迭代,并使其成为集成/健康检查迭代,只是检查它在大局中的情况。

您可以让客户每周/迭代一次在现场为您进行一些测试吗?

最后,我同意 Phil 的回答,这应该是您的最终目标,但我也明白,很多时候在短期内拥有一名全职的专职测试员在财务/现实上是不可行的。

听起来像迷你瀑布而不是敏捷。你怎么知道故事已经完成而不是刚刚完成?让自己成为一名优秀的测试人员并让他们适应,这就是我正在做的:)

听起来您正在为回归测试安排时间。持续的自动化测试方法将缩短您的测试周期。我会考虑围绕这个想法设计您的自动化套件,并在每晚运行它以进行 GUI 和服务测试(或者如果您有雄心壮志,则更多),同时在所有构建上运行单元测试。每晚自动化的回归套件可能会将您的测试需求减少到仅一天或半天的测试(就像您说的很难自动化所有事情)。此外,您将获得有关您的质量的价值夜间反馈。

当然,这是一个微妙的平衡。您需要找到时间来创建、管理和维护它。您可以看到它如何很容易地导致建议向您的团队添加测试人员以帮助管理它。

管理推销:

  • 添加测试人员可以将您的测试周期缩短 1 天。如果您运行 2 周的 sprint,那么每年将增加 26 天的开发时间(多 2 1/2 sprint)。我不确定你的团队有多大,但很可能应该很容易支付测试人员的薪水。当然,测试人员最好是摇滚明星。

为了补充 Lyndon 的答案,也许您可​​以以更正式的方式分配开发人员与测试相关的活动。如前所述,自动化测试很棒,因此请考虑将它们与生产代码一起作为开发重点。指定的开发人员可以全职或兼职编写和维护测试,并使它们保持最新并符合当前的编码标准。像对待生产代码一样对待测试代码可能会对您的测试过程有所帮助。

除此之外,如果您让开发人员维护自动化测试,他们可能会至少对软件进行一些“手动”测试,这是一个好处。再次,将这些过程视为一等公民;允许开发人员或任何其他正式的时间来探索和手动检查您的软件,无论是出于自动化目的还是其他目的。不要只在有时间的地方进行测试;拥抱它以了解您的软件。

最后,如果您发现自己在想“我真的认为我们需要一个 QA/测试团队”,请将其作为优先事项。找出最适合您的团队的方法并坚持下去。预算适用于各种事物,包括新员工和资源。