当团队没有得到足够的需求时，哪些测试方法是合适的？

Question

所以，形势相当严峻。作为一名测试经理，我需要在团队遇到情况时创建一种方法:当需求和规范没有完成时，并且经常不满足准备测试的定义。老实说，我们并不总是对那个项目有百分之百的要求。

目前需求的情况似乎是不可改变的，所以我需要创建一种方法，当测试人员检查没有需求的产品时，这听起来有点疯狂。但我们需要适应。

在我看来，我们可以先尝试一些特别的会议，然后才能弄清楚我们的要求应该是什么。开发的特性应该以一种临时的方式进行测试(30分钟)，测试人员会收集问题和问题的列表，将这些列表传递给团队的其他成员(开发人员、设计师、经理)。

下一步是收集关于功能和设计的答案。在此之后，探索性会议开始(90分钟)。之后，它应该存储更多关于特性的信息，更多的问题，更多的缺陷，更多的答案，然后测试人员应该为最重要的测试用例创建一个测试设计。为什么？拥有用于回归检查的文档(在该项目中不应该很快自动化)。

因此，这个计划就像：

ad-hoc -> collect information -> 
exploratory -> collect information -> 
test-design (most important cases) -> 
exploratory + documented testing (final checks) -> 
moving to regression 

你对此有什么想法吗？它应该有效吗?我怎样才能改进这种方法？

Answer 1

在上述情况下，我喜欢测试业务目标，而不是严格的需求。您的应用程序具有特定的功能，实现可以支持它实现该功能，也可以阻止它。任何障碍都将被视为缺陷(通过产品所有者进行过滤，因为某些不直接支持业务目标的实现可能仍然需要，因为现实生活很混乱)。

使用这种方法，您当然会遇到某些问题，首先，您需要真正了解您的业务案例和用户，以准确确定哪些帮助和阻碍他们。其次，您将报告问题，浪费您的时间以及其他人的时间，因为您的问题需要由能够就应用程序的行为做出决定的人进行审查。第三个大问题是，您将错过更多的问题，因为那些被支持但并不明显的案例，在没有需求告知测试团队的情况下会被忽略。

所以问题是你的公司是否愿意接受这些权衡。我的建议总是处理导致QA无法获得他们应该测试的特性的需求的过程问题，但是如果接受测试过程中增加的复杂性和降低的效率，使用核心业务用例作为指导通常是处理这种情况的最佳方法。

Answer 2

需求很少是完全的，并不是因为人们草率，而是因为我们在创建它们的过程中弄清楚了问题。因此，优秀的测试人员应该始终以批判性的眼光阅读需求，并采用其他测试策略。

话虽如此，但重要的是要创建一个环境，让人们能够真正地一起工作，并且测试人员可以访问不同的涉众。

在过去的类似情况下，帮助我的是：

• 与开发人员密切合作，甚至可能一起测试。
• 与商界人士接触并向他们提出问题
• 向人们展示新的特点
• 让人们在测试环境中使用新特性。
• 或者至少展示一些其他工作产品比如截图..。所以人们可以看到它(应用程序，功能，.)，而不仅仅是阅读它
• 以前有过商业领域的经验，类似于应用程序，对此有很大帮助。

最后但并非最不重要的是，有时间的探索会议是很好的，然而，我不会试图强加给测试人员任何特定的期限。雇佣有兴趣的人，让他们自由地建立自己的工作规则。

Answer 3

“好的测试需要平衡降低风险的需要和试图收集太多信息的风险。”--曾傑瑞·温伯格

实现3次朋友会议

在这种情况下，我将精确地实现3个位朋友会话，以便作为团队对以下内容形成共同的理解：

• 生意-我们想解决什么问题？
• 开发--我们如何建立解决这个问题的解决方案？
• 测试--我们如何才能有效地测试这个解决方案？什么可能会出错，这对商业来说是至关重要的？

会议结构

我建议只在3名团队成员之间举行一次会议--业务分析师、开发人员和每个新特性故事的测试人员.These 3都应该是真正从事该故事工作的人。其他团队成员一般应该被排除在外，这样就可以让3位紧密合作的团队成员能够非常集中地会面。

持有这些不同观点的人应该合作来定义该做什么，并就如何知道什么时候做正确的事情达成一致。这种协作的最终结果是更清楚地描述工作量的增加-通常是以实例的形式，从而为团队带来共同的理解。

预期收益

建立对增加工作量的意图的共同理解。

及早发现误解和困惑，并允许在交付增加的工作量过程中更早地学习。

为应参与讨论任何特定增加的工作量的人数提供合理的护栏。

来源：3次Amigos会议