在我们的学习中，frieda扮演着专注于测试用例的经理的角色，并且做得很好。 她打了一张典型的管理卡：“了解产品怎么样？ 测试案例不是这样做的好方法吗？”其中性能测试工具给了创业者很大的精神支持，未来会有更多的创业者为这个行业贡献自己的力量。
在“快速软件测试”中，我们说测试是通过探索和试验来学习产品，从而对产品进行评估，包括提问，建模，学习，操纵，进行推理等。因此，学习是测试的重要组成部分。 测试人员可以与许多人工制品和人员进行互动，以开始了解该产品，我已经讨论过了。 让我们看看为什么让测试人员在测试用例中工作可能不是一个好方法。
尽管吹捧测试用例是了解产品的一种手段，但根据我的个人经验，测试用例对于此目的并不是很有帮助。 您是否曾经在google maps的指令列表，导航系统的合成语音甚至其他人的语音指令的引导下开车到某个地方？ 我的经验是，让别人指导我的行为会使我脱离寻路和感性认识。 当我到达目的地时，我不确定如何到达目的地，也不确定能否找到回程。
如果我想学习并坚持下去，我学习的重要部分必须是自学的。 我必须时不时地了解自己去过的地方，现在在哪里以及要去哪里。 在此过程中，我必须感到某种程度的困惑和小障碍。 我必须注意到对我而言有趣且重要的事情，以便我可以与旅程联系起来。 我必须有做出和纠正小错误的自由。
遵循详细说明可能有助于有效地完成某些种类的任务。 但是，遵循说明可能会妨碍您学习某些东西，而测试的主要任务是了解产品及其状态。
您可以通过向测试人员挑战一组测试用例，以发现其中的问题，或者尝试找出它们的动机，来更改任务，这可能会产生一些有用的见解。
但是，如果您真的希望测试人员了解该产品，那么我将按照以下方法进行操作：给他们一个任务来了解该产品。 今天，我们将介绍一些学习任务，您可以在测试人员参与的过程中或您自己的早期应用这些任务。 这样的任务往往是广泛而开放的，并且针对具体的风险和问题的针对性比以后更高。 我将提供一些示例，并在每个示例后加注。
“就新功能采访产品经理。 确定三到六个用户角色，并（除您的其他注释外）创建一些草图或白板图，以说明他们可能如何使用该功能。 在对话中，提出并讨论阻碍工作流程的障碍或中断的可能性。 做笔记和照片。”
正如上下文驱动测试的原则所指出的那样，该产品是一种解决方案。 如果问题仍未解决，则该产品将无法正常工作。 当产品提出新问题时，从客户的角度看，它可能也无法正常工作。
“参加新功能的计划会议。 询问对我们正在建造的建筑的描述； 我们为谁而建？ 他们可能会遇到什么样的问题； 以及我们如何将它们识别为问题。 定期提出有关可测试性的问题。 记录会议讨论内容。”
计划会议往往集中于预见成功； 故意的。 这些会议提供了讨论失败的机会。 关于我们或客户可能无法实现目标或遇到问题的方式。 计划产品还涉及计划方式，以注意产品可能会出错。
“与开发人员或高级测试人员一起对该组件的功能进行演练。 收集产品中的功能实例或产品处理的数据，这些实例可能表示异常或极端情况。 收集可能会触发极端或异常行为，或者可能使产品处于不稳定状态的测试条件集。 创建一个风险列表，重点关注可能导致功能错误或数据丢失的对功能，可靠性和数据完整性的威胁。”
用快速软件测试的话来说，测试条件是在测试过程中可以检查的东西，或者可能改变测试结果的东西。 在我看来，当人们使用正式的过程测试用例时，他们的目的通常是检查特定的测试条件。 但是，可以使用许多不同种类的工件来收集和检查这些条件：表格，列表，带注释的图或流程图，思维导图…
“请与用户手册的撰写者一起查看产品的规格。 除了保留的任何注释或图表外，还要对规范的内容进行编码。 （注意：此处的“代码”用于定性研究，而不是用于编写计算机代码。）也就是说，对于每个带编号的段落，请尝试识别至少一个和多达三个明确定义的质量标准 或暗中提及。 整理结果，寻找几乎没有提及或完全缺失的质量标准，并注意寻找神秘的沉默。”
关于测试存在一个普遍的误解：测试人员会寻找产品与产品说明之间的不一致之处，仅此而已。 但是优秀的测试人员会查看产品，产品说明以及产品用途，并在所有这些内容之间寻求不一致之处。 我们的许多意图是默契的，不是明确的。 另请注意，设计者对用户任务的模型可能与用户模型有很大不同。
请注意，上面的每个示例都包含一个信息任务。 每个任务都包含一项任务，任务是产生特定的，可审查的工件，以便可以通过对话和书面证据来评估测试人员的学习情况。 汇报和将学习与他人联系是总体测试的重要组成部分，尤其是基于会话的测试管理。
每个示例还涉及与团队中其他人员的协作，以便可以识别和讨论观点之间的不一致之处。 请注意：这些只是示例。 它们不是要遵循的模板。 重要的是您要根据自己的工作环境来制定自己的任务。
在测试人员参与的早期阶段，发现问题并不是重点。 学习是。 但是，作为一个有益的副作用，学习可能会发现一些错误或不一致，然后才将其转变为产品中的错误。 另一个好处是，测试人员和团队可以为产品和项目风险列表收集想法。 最后，学习可能会揭示可以用工具有用地检查的测试条件，或者可能对于通过显式程序进行验证很重要的测试条件。
frieda说：“有时候经理说，当我们与母语不是英语的离岸团队打交道时，给测试人员明确的指示很重要。”
测试用例真的会使这个问题消失吗？ 大概测试用例和产品也将用英语编写。 如果测试人员不能很好地理解英语，那么他们将几乎无法很好地阅读测试用例，理解要求或标准，或者理解产品试图通过其告诉他们什么（大概也是英语）用户界面。
也许将产品和周围的工件从英语翻译成测试人员的母语。 这解决了一种问题，但引入了一个新问题：即使每个人都用英语工作，要求和规格，设计和行话也会经常被误解。 翻译该材料时，翻译中不可避免地会改变或失去某些含义。 所有这些问题都需要关注和管理。
如果某件产品做重要的事情，则很可能存在重要问题的风险，其中许多问题是测试用例无法预料的。 让熟练的测试人员合理快速地学习产品，同时又深入地训练他们以寻找和识别重要的问题，这不是一个好主意吗？ 当测试人员启动并运行一个项目时，可以使他们的工作集中精力而又不会过度集中精力。