整个团队想要成功地践行敏捷测试方法，意味着需要对即将发行的功能进行大量的对话。这些对话可能始于项目的开始阶段、设计评审、迭代前或迭代规划会议。如果我们要成功地交付业务、客户和用户所期望和需要的内容，我们需要对每个功能进行深入了解。
最近，我们尝试着整理了一份“备忘清单”，其中包含了在讨论计划中的新功能和故事时可以提出的问题。Lisa发现，在这些对话中参考可能的问题列表有助于她思考出好问题。并非所有这些问题都适用于每个功能集或故事，但只要看一下列表，就能帮助产生良好的对话起点。答案可能会揭示一些我们之前没有意识到的前提条件，并有助于确保所有的测试活动在需要时都能进行。
我们为这份”备忘清单”想了一个简短、响亮的名字，可以称它为“需牢记的功能测试问题”或“功能质量对话备忘单”，但这些都不够简短和吸引人！经过一段时间的意见征集，我们最终叫它 “功能聊天单：对话开场白”。
无论如何，请随意下载这份备忘清单，看看它是否能帮助您进行富有成效的对话，帮助您的团队建立对每个功能及其测试方式的共同理解。
以下是相关对话内容：
对用户/企业的价值
- 故事的目的是什么？
- 它能为用户和我们企业解决什么问题？
- 一旦功能发布，我们如何知道它是否成功？我们能在什么时间范围内衡量什么？我们是否需要新的分析方法来获得生产中的使用指标？
功能行为
- 业务规则是什么？
- 对于每个规则，至少提供一个正常路径的示例，最好还有一个错误行为的示例。
- 谁会使用这个功能？具体是哪种角色，从事什么样的工作？
- 用户在使用这个功能之前会做什么？使用之后呢？
- 当有人使用它时，最糟糕的情况是什么？（暴露风险）
- 最好的情况是什么？（让客户感到满意）
- 故事/功能/史诗是否太过庞大？我们能否交付一个简化版本并获得反馈？
- 注意范围扩张和过度设计！
质量属性
- 这会影响性能吗？我们将如何测试？
- 这是否会带来安全漏洞？我们将如何测试？
- 这个故事是否会带来任何可访问性问题？
- 哪些质量属性对这一功能和上下文很重要？
风险
- 是否有新的API入口点或服务器命令？它们会遵循当前的模式吗？
- 我们的团队是否拥有这方面的所有专业知识？我们是否应该寻求外部帮助？
- 这是否在功能标志之后？自动测试是否会在功能标志打开或关闭的情况下运行？
- 移动端/web端是否有受影响的风险？
- 系统的其他部分会受到影响吗？
可测试性
- 我们将如何测试？
- 有哪些自动化测试—单元测试、集成测试、冒烟测试？
- 我们是否需要大量的探索性测试？
- 我们是否应该编写一份高水平的探索性测试章程，说明该功能/特性的测试重点？
- 我们是否有合适的数据来进行测试？
- 是否需要更新现有测试用例或添加新测试用例？如果是新的测试用例，是否需要学习新技术？
