克雷格，我在类似的环境中工作了 6 年。DEV 和 QA 在同一个盒子上，使用不断变化的相同代码。在我进行测试时，开发人员会检查程序、更新和重新编译。起初，我和你一样很沮丧。如果可能的话，我会创建自己的“沙盒”（仅限数据库，而不是实际程序），但有时由于添加了大量新程序，这是不可行的。有时我会在会话失败之前收到警告，但通常我不会。一点背景：

1. 我们有 2 名测试人员，您的真实身份和 1 名其他测试人员。
2. 我们支持 5 名开发人员，偶尔还会支持 1 或 2 名以上。
3. 我们有 1 个核心工具可供客户购买，其中包含 12 个可选模块、5 个要支持的软件版本、5 个要支持的操作系统版本和 3 个要支持的平台（IE 和 FF 是唯一的浏览器）。
4. 无论发生什么其他情况，QA 都会验证我们自己的错误和客户（错误修复一直在出现；当维护开发人员被拉到新开发人员时，没有像那里那样的中断）。
5. 我们坚持每 60 天左右推出服务包版本，每 18 个月左右推出新版本。
6. 所有这一切都是在非常少的（如果有的话）要求的情况下完成的。

这听起来是不是很熟悉？

郑重声明，我没有抱怨；我在陈述事实。这种环境对我们的团队非常有效。与任何团队一样，总有一些事情我会改变/改进。我们有一个非常忠诚的客户群，这对我们的系统及其成功很有帮助。

根据您所写的内容，克雷格，我听到了 2 个挫折：

1. 我怎么可能在这样的环境中进行彻底的测试？构建不稳定，错误修复会影响其他模块，我不想错过任何东西。
2. 截止描述是最佳解决方案吗？

第 1 点：接受无论你测试得多么彻底，你都会错过错误。我们团队所做的并且目前运行良好的是我开发了一个“迷你回归”套件，它涉及所有模块，只测试非常核心的功能。我对它进行加权和缩放，以便在紧缩时不会触及较低的加权区域。其中大部分是带有很少错误的遗留代码。

第 2 点：我建议在您自己的“代码冻结”的 2-3 天期间，您要求开发人员主动进行代码更改，并告诉您程序 x 正在更改。这只有在他们知道只有几天的情况下才会起作用。不要担心它是否敏捷。找到最适合您的团队和环境的方法，然后继续使用。

至于自动化：如果维护脚本所需的时间与手动测试脚本所需的时间一样长，那么请不要打扰。我们的自动化为零，因为需要 1 个人全职来管理它。

如果可以的话，最后一件事。你的理智：保护它。为此，将您的困境提交给您的经理，按照他/她的建议做出回应，然后放手。你知道你正在做你能做的最好的工作，超越。在这种环境中找到积极的一面，向他们学习并坚持下去。您将在今天和将来使用它们。

阅读您的帐户后，我有几个问题。起初它们可能听起来很苛刻，但在我看来，您的帐户听起来就像您所在的组织必须考虑一些严酷的现实。

1）这里的问题是复杂性，还是你对复杂性的反应？（以及您的组织对复杂性明显缺乏反应？）

2）您的程序员是否需要编写他们可以保证可以工作的代码，或者他们只是需要编写代码？

3）你有没有在那里工作的经理，或者每个人都只是做他喜欢的事？

几个具体点：

我们目前正在使用看板的“敏捷”方法来跟踪所有工作项。

尽量不要将“方法论”与“实践”或“工具”或“技术”，甚至“方法”混为一谈。方法论是对方法的研究。现在，这可能看起来像我很迂腐。那不是我的本意。然而，我观察到人们经常使用宏大的词来掩盖不那么宏大的知识或对需要持续学习的主题的采用。

我的问题是我发现自己有时很难掌握一切，很多应用程序都依赖于其他应用程序。因此，即使一个应用程序在技术上没有更新，它仍有可能受到其他地方的更改的影响。

如果您没有将所有这些都视为问题，而是将其视为测试结果——测试揭示的问题的证据，会发生什么？事实是，难以理解的相互依赖关系对产品来说是一个问题，最终对业务来说也是一个问题。由于您无法控制代码和相互依赖关系，因此您无法更改它 - 但您可以确定将其报告为问题。任何使测试更难或需要更长时间的事情都会让产品中的任何错误隐藏更长时间，这会增加风险。

此外，由于应用程序的不断开发，很难获得稳定的构建进行测试。

这是同一问题的另一个例子。当你最终部署了一个足够稳定的构建以进行测试时，你在很多不确定性和极端时间压力下进行了一阵测试，是什么让你和开发团队和业务认为它足够稳定可以发布?

为了解决这个问题，我尝试引入一种“截止”期，在此期间没有人可以在发布前 2/3 天合并到我的测试分支（但是这个延迟期并没有让我觉得特别“敏捷” ）。

别担心；听起来你的团队所做的任何其他事情都不是特别敏捷，除了速度部分。

敏捷主义者（至少是 XP 人员）谈论的一件事是可持续节奏的概念。你的测试揭示了，你正在描述一个在我看来不可持续的速度。你可以问：“我该如何应对？” 但我认为在这里试图应对会增加问题。一个更重要的问题是，“开发团队将如何回应我透露的有关产品和项目的信息？”

有没有人在类似的工作环境中有任何经验并且有任何他们可以提供的建议，因为这已经到了令人沮丧的地步，显然更多的人在甲板上会很好，但这不是一个可用的选择。

更多的手在甲板上是一个可用的选项（虽然我不认为它会真正解决问题）。无论如何，这是您的企业选择拒绝的选项。他们还能做出哪些不同的选择？

---迈克尔 B.

在 5 比 1 的测试人员比例下，让开发人员编写自动化单元测试是我坚持的长期策略。

该问题描述了理解系统依赖关系（和相互依赖关系）的问题。我相信采用单元测试将推动一些行为，这些行为将使这些依赖关系在设计上更加明显。不过，这不是最终的答案，需要一些时间才能揭示这项工作的一些成果。

为了获得一些短期的缓解，我会召集一些会议来真正记录依赖关系。视觉上。包括每个组件 (dll)、每个数据库、每个 UI，甚至可能是每个脚本等。你不能包含太多。

首先让我说您有一组经验丰富且受人尊敬的测试人员的大量回复，请确保明智地使用他们的建议，我知道我会的 :)

我的情况完全不同，我们是一个中等规模的组织，它使用许多开发和测试环境来执行敏捷 Scrum 方法。话虽如此，我们每天进行数百次构建和部署。我们持续开发成功的关键依赖于单元测试、构建和部署自动化以及持续的沟通。

如果我遇到你的情况，我会专注于以下几点：

我什至无法真正描述单元测试对持续集成的成功有多大用处。话虽如此，这可能是您无法控制的事情，请务必推动它，但这是您自己无法做到的事情。

再次研究自动化。考虑到您是一支军队，我建议您将一组烟雾/健全性测试放在一起，以便首先从最重要的应用程序开始在部署时运行。我真的会专注于检查应用程序是否启动并响应请求的非常简单的事情。在每个部署上运行一个简单的套件（每个应用程序可能进行一到两个测试）将帮助您更快地发现问题，这是您非常缺少的 CI 的关键。

与开发人员一起进行代码审查。我发现这对于创建测试和了解代码在幕后的实际工作方式非常有帮助。此外，询问开发人员问题通常会在您开始测试之前发现问题。

与企业互动。您的公司对似乎每次部署都会出现的当前缺陷感到满意吗？如果不是，您可以推送更改以提高代码质量。

最后让我说，我其实有点羡慕你的情况。作为唯一的测试人员，您可以尝试您认为合适的新事物，看看哪些对您的团队有效。我有点控制狂，并且喜欢为您概述的问题找到解决方案的挑战。对我来说，弄清楚这一点是我们要做的很酷的事情。

祝你好运，测试愉快！