Sprint计划中的探索性测试或SBTM？

Question

我想把SBTM包括在我们的冲刺中。当然，要问很多问题。

• 探索性测试的区别在哪里？
• 更值得用时间盒进行探索性测试吗？
• 什么时间应该安排在90分钟？如果是这样的话，如何作为一个时间箱？
• SBTM所犯的错误是如何行动的？
• 我还可以自动化SBTM的区域吗？或者它真的只是一个手动的测试过程？

SBTM是基于所谓的会话，时间窗口约为90分钟.在这些会议中，在规划阶段确定的章程--一种议程--由测试人员完成。会议期间发现的要点包括在一份会议报告中，该报告将在一次汇报中讨论。在测试人员和测试管理人员之间进行了汇报，讨论了测试人员对测试对象的直觉和要点。根据会议报告和汇报所取得的经验，可以安排进一步的会议或修改以下章程。SBTM的优点是

• 灵活/敏捷方法
• 报告要尽可能精简。
• 根据新获取的信息，可以在每次会话后更改宪章。例如，如果are发现了新的风险领域，那么它们可以在接下来的会议中进行测试，即使a最初设置了不同的议程。

Answer 1

作为探索性测试的崇拜者，我可以尝试回答以下几个问题：

探索性测试的区别在哪里？--没有区别。基于会话的测试管理(session based，简称SBTM )只是测量探索性测试的一种方式或方法。例如，假设您在办公室做了一整天的探索性测试，现在您必须向Manager报告。由于没有正式的测试用例或文档，所以很难告诉经理一整天你做了什么。答案太主观了。SBTM提供了测量能力。

更有价值的是时间盒的探索性测试吗？-是的。SBTM的协议/亮点之一是在“会话”中进行探索性测试(即时间装箱测试)。

什么时间应该安排在90分钟？如果是这样的话，如何作为一个时间表呢？--这完全取决于QA和项目经理的讨论和决定。对于简单的web应用程序，与复杂的应用程序(使用web+ api +数据库+网络)相比，会话可能比较小。

SBTM所犯的错误是如何行动？--问题还不清楚。抱歉的!

我还可以自动化SBTM的区域吗？还是真的只是一个手工测试过程？-是的，我们可以自动化。然而，大多数探索性测试是由熟练的领域/应用程序专家QA人员完成的，没有适当的文档/测试步骤/测试用例。因此，在测试步骤不明确的情况下，自动化是很难实现的。