摘要：许多团队在为创建测试而挣扎，由于缺乏沟通和缺乏需求，测试人员没有参与设计或讨论，时间短缺，或者不完整的信息。这样的测试将在质量和完整性上备受考验。我们必须努力争取得到所需需求。
创建测试可能是软件测试最重要的一个方面。虽然我们的重点是测试的执行和生成报告，因为这是最明显的测试输出，但整个过程的基石在于建立准确和有意义的测试。
许多团队都在敏捷之旅中为创建测试而挣扎，他们经常在测试设计和创建过程中做很多的猜测。这可能是由于缺乏沟通和缺乏需求，测试人员没有参与设计或讨论，时间短缺，关于测试环境或工具使用的不完整信息，或者不知如：相关的积极和消极场景的测试和应用的目标及范围。
创建测试中匆忙的猜测，在项目的后期可能会引出更大的问题，会对整个产品的质量构成风险。
比方说你的团队必须测试一个网页。除了一些页面控制的功能规格，他们没有太多的信息。但他们在测试启动之前需要决定这么多事情，比如要在哪些浏览器上测试，采用哪款基于识别各类控件的自动化工具，执行哪些工作流作为这页和整个站点集成测试的一部分，等等。
关于网页的这些功能规格是非常重要，它的控制，以及怎么验证每个控制的完成和通过。当团队设计创建测试计划和测试方案时，模糊和缺失的需求将导致他们需要根据个人经验来假设大量的参数，并猜测某些情况。例如，测试人员可能假定他所安装版本的Chrome作为测试和使用的默认浏览器，而不征求用户的偏好和所需要支持的所有版本。
假设在网页上的一个username字段，在规格中没有指定它的长度限制和允许输入的字符校验。那测试人员可能假定它是标准的10字符长度限制，只允许输入字母并按此测试，而不问明有关区域和特定范围的需求。如果网站有法国用户，那他们的名字会包含特殊字符，或者印度用户的名字经常会超过10个字符，测试人员的假定和猜测应用于测试，这些输入将失败。
另一个团队可能面临的问题是猜测测试数据。你是否使用适当的技术来获取测试数据值，或者仅仅猜测随机值去输入？假设你正在测试加法的功能。你是随机发送输入的数字并验证输出？我们应该使用适当的设计技术，例如等价类划分法或边界值分析法来获取一组恰当的测试数据值。
这是多么可怜的沟通或缺乏方向所导致的错误测试设计。在实际开始测试之前，我们需要尽可能减少这种猜测并作出明智的决定。
当在一个敏捷项目中我们面临缺失和模糊的需求时，我的团队很快意识到这点。我们注意到，由于上面提到的很多因素，当我们在设计测试时潜意识的假设事情，随后实现的假设是不正确的，意味着我们提的许多缺陷被标记为无效，我们不得不重做大量的工作。这时我们决定要克服这个问题。
测试团队开始要求：被允许参与到需求阶段，以及用户情节构建和设计讨论之中。这样更好的明晰了大量的要求和功能，这也最终受用于整个团队，因为我们从测试的角度去发现设计和需求上的问题，帮助更好的从用户情节来编写文档，这将在后面形成我们的测试依据。
沟通的作用在这里还强调的不够。我们鼓励队友们询问开发更多的测试信息，比如采用哪个环境，哪些将影响我们的测试，等等。基于这些坚定的事实和细节，我们的测试将更加有用和成功。
另一个好主意让整个测试团队参与进去，而不是一个或两个团队成员创建测试而其他人的工作仅是执行它们。我们分享所测试的功能细节给所有的测试人员，和每个人合作来创建测试。每个人都会给出自己的观点和意见，挑战对方的假设，这样的测试必然更加详细和详尽。
回顾上面形成了解开我们测试眼界的一个重要方面。在我们的测试上，得到同行测试人员，开发人员，测试经理，以及产品所有者做出一些友好的评论，以确保我们没有限制在主观的想象和个人观点上。这打开了许多从未接触的区域，从而避免了猜想。这也给了我们信心，每个人都在测试设计上签署了名字，后面我们提出的bug将会是有效的。
如果没有足够的信息和沟通去创建你的测试，那不意味着你应转而猜想。这样的测试将在质量和完整性上备受考验。我们必须努力去得到所需的详细信息，然后才根据坚定的依据来创建我们的测试。这样最终将减少大量返工，做出更有价值的测试。
本文由ruink译自Nishi Grover Garg的《Don’t Guess Your Tests—Strive for Complete Requirements》一文。