参与测试

测试反模式

有一个我经常遇到的常见反模式，涉及到测试。在这个反模式中，测试是关于在项目接近尾声时发现技术缺陷。测试人员认为他们的工作是防止一个有bug的产品被交付给客户。为了完成这一点，测试人员从需求文档中定义测试用例。由于需求在项目期间会发生变化，测试人员需要等到项目接近尾声时才产生他们的测试。

这有什么问题？

此模型不起作用。要求文件首先没有讲述完美的故事。并且文件永远不会完美的一致性。有时测试仪会与开发人员不同地解释要求。不可避免地，开发提供了与测试人员期望的东西不匹配的东西，他们提出缺陷。为避免缺陷，开发人员必须预测需求可能意味着的一切。结果是开发人员显着过度建设或过度工程师。该产品的更大和更“动态”，测试努力越大。

反模式的结果是，生产可工作的、经过测试的软件的成本显著增加。我们是不容易被预测的，直到项目非常晚的时候，我们才真正知道我们在哪里。因为我们测试的时间较晚，我们在项目中发现我们没有达到计划、范围或成本。我们在责备游戏中结束，试图决定缺陷是需求问题、开发问题还是测试问题。这是一种恶性循环，产生了低信任和缺乏合作与协调的文化。这是非常普遍的——我每天都能看到这种低协作环境。

在构建之前定义验收标准

测试（n）：批判性评估的程序;一种确定某事物的存在，质量或真实性的手段。

测试不是寻找bug。这不仅仅是评估。测试中的一个关键活动是为评估定义标准——我们将这些称为验收标准。正如我们在上面指出的，当产品构建完成后，有人在竖井中设置评估标准时，它是无效的。我们想要定义验收标准之前我们建造这个东西。这不会给测试人员带来更多的成本。无论您在之前还是之后编写测试用例，都不再是最初的工作。

定义作为整个团队的验收标准

在此之前定义它们是不够的。每个人都需要对结果有一个共同的理解。在关于定义接受标准的讨论中有很多好处。当我们事先就测试达成一致时，开发人员就可以构建最小、最简单的东西来解决问题——而不是试图预测需求可能意味着的一切而过度构建。当我们就如何在构建产品之前评估产品达成一致时，我们将会有更少的缺陷，因此返工也会更少。

逐步详细阐述验收标准

在你构建某样东西之前定义验收标准并不是大的预先设计。我们想要做全队即时的详细设计。在Scrum中，这发生在梳理backlog和Sprint计划时。在我们的企业敏捷方法中，我们在产品路线图中将产品分解为一系列的发布版本。在发布计划期间，我们将发布分解为特性。我们将特性分解成故事，并在Sprint计划之前进一步细化故事。

随着我们逐步细化需求——我们逐步细化接受标准。事实上，接受标准是在故事级别表达业务规则的有效方法。亚博vip9通道我们还发现，非功能需求、遵从性需求和操作需求可以表示为特性级别的接受标准，这样我们就可以确保随着项目的进展，我们正在完成产品的所有方面。

更好的测试策略

我们正在解决测试问题。当验收测试被共同阐述时，测试人员、分析人员和开发人员没有不同的理解。当我们在构建之前对它们进行细化时，开发人员就可以构建最小、最简单的东西来解决问题。当我们细化接受标准的同时，我们细化需求，我们没有那么多的变更控制需要，我们实际上得到了更好的需求来沟通。这种策略对降低测试成本和产品发布时间有很大的影响。