您不需要测试人员–是吗？

我与大型和小型软件开发组织中的许多人进行了交谈，讨论了他们如何管理软件开发，如何组织它们，遵循什么实践以及什么实践有效。 我与之交谈的大多数团队中的大多数人都不能证明让某人仅测试他们的应用程序是合理的，因为测试人员实际上并未构建软件，因此将其视为开销。 这意味着开发人员需要自己测试软件，否则客户将必须进行测试。

测试人员在敏捷团队中做什么？

不少敏捷团队认为您不需要测试人员即可交付有效的软件。 测试人员被视为瀑布时代的遗物（需求，设计，代码，然后传递给测试）。 在XP团队中，每个人都是开发人员，开发人员负责测试自己的代码，编写自动化的单元测试，然后自动执行客户定义的验收测试 ，并对此负责。 Scrum根本没有解释测试的完成方式-团队将在“检查并适应”良好实践的过程中找到解决方法。

如果开发人员已经在测试自己的代码（甚至可能正在配对以审查编写的代码），那么您需要测试人员做什么？

珍妮特·格雷格里（Janet Gregory）和丽莎·克里斯平（Lisa Crispin）写了一本大书，证明了测试人员在敏捷团队中的作用，并向程序员和测试人员解释了测试人员如何适应敏捷开发，但这并没有改变很多团队的态度，尤其是在“工程设计团队”中。驱动文化”（由程序员创建的初创公司）。

他们的论据之一是，敏捷团队对于测试人员而言太快了，黑匣子测试人员编写测试计划并通过手动测试脚本工作或不断更新其Quality Center或Selenium UI回归测试永远无法赶上提供新功能的团队。短跑冲刺。 如果测试人员没有技术技能，至少不能用Fitnessit或Cucumber之类的工具编写验收测试 ，或者他们不具备业务领域知识以帮助填写客户/产品负责人并回答开发人员问题，他们有好处吗？

在“ 持续部署”中 ，这是极端的，这种做法在像IMVU和Facebook这样的公司中很流行，开发人员在其中审查他们的工作，编写自动化测试，检查代码并进行测试，如果测试通过，则更改将立即自动推送到生产。

让客户测试您的工作

一些商店将持续部署看作是通过吸引客户为他们进行测试来“众包”测试的机会。 它实际上是作为一种竞争优势而被推广的。 但是，就像我之前看到的那样，以这种方式编写安全可靠的软件确实非常困难，甚至不可能。 要对不断向客户部署的系统质量进行严格的评估，请阅读James Bach在20分钟的有趣文章中测试了一个海报子应用程序中的“持续部署”以及他们在短时间内在应用程序中发现的问题。 。

其他“持续部署”部门则更加谨慎，并遵循Etsy / Flickr的暗中启动方法 ：连续部署变更，但在为客户逐步启用变更并密切监视结果之前进行测试和审查。

无论如何，重要的是要记住，客户可以测试某些事情，而实际上只有客户可以测试：某项功能是否有用，某项功能是否可用，他们正确执行任务所需的信息种类，最佳的工作流程是。 这就是A / B拆分测试的目的–尝试想法，功能和工作流程，收集使用数据，并找出客户最喜欢或最喜欢使用的东西，而不喜欢的东西。 评估替代方案并获得反馈。

但是，您不要求客户测试某些事情是否已完成，代码是否有效，系统是否稳定可靠，是否在负载下运行。

您的测试团队需要什么？

即使是最优秀，最负责任和经验最丰富的开发人员也会犯错。 在我们的商店中，每个人都是经验丰富的开发人员-其中一些已经在此领域工作了10-15年或更长时间。 他们会仔细测试自己的工作，并为每次签入更新自动单元/功能测试套件。 这些测试和静态分析检查是在持续集成中运行的-我们已学会严重依赖测试套件（现在有成千上万的测试具有较高的覆盖率）以及静态分析错误检查和安全漏洞检查工具查找常见的编码错误。 所有代码更改都将由另一位高级开发人员进行审核-毫无例外。

即使拥有良好的纪律和良好的工具，优秀的程序员仍然会犯错误：一些细微的（不一致，外观和感觉问题，数据转换和设置，缺少编辑）和一些基本的（加载时运行时故障，并发问题，错过的需求） ，规则错误，错误处理错误）。 我想确保在客户这样做之前，我们发现了大多数（如果不是全部）错误。 开发人员也是如此。

这就是我们的测试团队的来历。我们有一个经验丰富，非常专业的小型测试团队。 一位测试人员专注于验收测试，验证功能需求以及与企业的可用性和工作流程。 另一位测试人员致力于功能回归和业务规则的正确性和覆盖范围，寻找缺失的规则和开发人员测试套件中的漏洞，并在API级别上自动化我们的集成测试。 另一个测试人员的主要工作是操作测试，压力测试（针对峰值和需求冲击）以及浸泡测试（以查找泄漏和GC问题），破坏性的系统测试和错误查找-积极尝试破坏系统。 他们都知道足够多，可以在某人不在时互相补充，但是他们每个人都有自己独特的知识，技能和优势，以及解决问题的方式。

当我们刚开始构建系统时，我们从一个更大的测试团队开始，更加专注于覆盖范围和保证，提供测试计划和可追溯性以及详细的手动测试清单，并在UI上编写自动回归测试。 但是，这样浪费大量的时间和精力。

现在，我们更多地依赖于由开发人员在UI下编写的自动化测试来实现功能覆盖和回归保护。 我们的测试团队将大部分精力投入到探索性功能，系统和运营测试，基于风险和针对客户的针对性测试中，以发现最重要的错误，发现弱点并加以利用。 他们喜欢这种方法，我喜欢它，开发人员也喜欢它，因为我们在测试中发现了真正重要的错误，逃避代码审查和单元测试的各种问题。

一旦开发人员签入了不同的客户配置，它们就会立即抽出测试更改。 他们与开发人员一起测试新功能，并与开发人员进行战争游戏和模拟，以尝试发现运行时错误和竞赛条件以及“现实”条件下的计时问题和工作流程问题。 他们使系统发生故障，以确保故障检测和恢复机制正常工作。 他们测试安全功能，并与顾问一起设置和管理笔测试。 他们将系统运行一天。 他们还与Ops一起处理与新客户和合作伙伴的集成认证。 他们与团队的其他成员一起进行短距离冲刺，每2周（有时更频繁）发布一次。

测试团队还负责将软件投入生产。 他们将每个版本放在一起，检查依赖关系，决定何时完成发布，将其发布到什么版本中，什么将不发布，他们检查我们是否已完成团队同意的所有审核，并测试了回滚和数据转换例程，然后它们与Ops一起将发行版部署到生产中。
他们不会降低团队速度，也不会阻止我们交付软件。 他们可以帮助我们确保该软件能够正常运行，并且可以安全地投入生产。

测试人员发现的不仅仅是错误

我已经在高保证，高诚信度的企业工作了很长时间，在这些企业中，没有测试员是不可行的选择–犯错误的风险太大了。 但是我认为，如果没有其他人来测试它，您就无法构建真正的软件。 除非您是一个早期的初创公司，需要提供概念证明，或者您是一个为内部使用而琐碎的小团队（但是您可能不会读懂此书），否则您需要帮助测试系统以确保其正常工作。

无论您的工作方式如何，遵循哪种方法–敏捷或瀑布式测试都不会改变对测试人员的需求。 如果您要快速而轻松地移动，则测试人员需要适应节奏以及他们获取和共享信息的方式。 没关系。 好的测试人员可以做到这一点。

我还不够幼稚（没有更多）认为测试团队会发现系统中可能存在的所有错误，或者这是他们的工作。 当然，我希望测试人员能够在客户发现之前发现任何重要或明显的错误。
他们需要我做的是帮助我们回答一些重要的问题：我们准备释放了吗？ 什么太粗糙，不稳定或不完整，什么需要撤消，什么需要进一步审查，或者重写？ 设计的弱点是什么？ 我们在哪里缺少自动化测试？ 我们在哪里需要更好的测试工具？ 哪些功能太难理解，不一致或难以设置？ 什么错误消息丢失或误导？ 我们是否试图做太多，太快？ 为了使系统更好，更可靠，我们需要更改设计，代码或设计或编码系统的方式吗？

测试不能提供所有可能的信息，但是可以提供一些信息。 良好的测试将提供许多有用的信息。
詹姆斯·巴赫（满意）

没有测试人员，您不仅会发布本不应该包含应该捕获的错误的代码，而且还会丢失许多有关软件的真正优势以及为使软件更好而需要做什么的重要信息。 如果您关心构建好的软件，那么这是您不能错过的机会。

参考： 您不需要测试人员–是吗？ 来自JCG合作伙伴 Jim Bird在Building Real Software博客上的介绍。

翻译自: https://www.javacodegeeks.com/2012/05/you-dont-need-testers-or-do-you.html