您如何为探索性测试会议编写清晰、简洁的测试章程?

软件测试 探索性的 sbtm
2022-01-10 15:38:37

基于会话的探索性测试依赖于以正确的详细程度创建良好的测试章程来指导测试人员,而不是指导他们。

您需要明确会话的目标,既不要过于笼统(因此不清楚会话的预期重点应该是什么),也不要过于指示性,从而限制测试人员设计自己的测试以响应他们正在发现什么。对于主要在脚本繁重的环境中工作的测试人员来说,通常很难避免陷入创建“假”章程的陷阱,这些章程实际上只是伪装的测试用例。对我来说,为会话编写清晰、简洁的测试章程是我在探索性测试中必须学习的最难的技能之一。

如果您是一位经验丰富的探索性测试人员,哪些属性对您来说是一份好的测试章程?

您是否使用任何通用模式来帮助您构建章程?在糟糕的测试章程中,您是否注意到任何常见的失败模式?

4个回答

你可能会发现自己很早就想写一堆章程来展示管理类型,这样看起来你就不会坐在你的手上。如果你发现它在你身上,请抵制这种冲动。

没有必要使章程过于复杂。如果开始一个会话并且您意识到范围过于雄心勃勃,请根据您在测试中发现的新信息修改范围并记下您认为可能需要的任何新章程。

我在实践中发现,在项目(尤其是新建项目)的早期创建章程更加困难,所以我预先查看侦察章程以发现哪些领域是

  1. 复杂的
  2. 越野车
  3. 不完整或与我们的预期大相径庭

我还喜欢使用思维导图来整理我们想要探索的产品领域的清单,以及我们可能想要采用的测试类型。

根据对这些问题的回答,结合我们所做的任何其他风险分析,您可以开始确定您的部门应该是什么以及您目前可能需要创建哪些章程,并酌情确定这些章程的优先级。

我用来指导章程创建的启发式方法:

  • 章程应该足够简短,可以发推文。
  • 进行侦察,直到你明确知道你想进一步探索什么。

其他可能影响您如何组合章程的因素是您的测试人员的经验。但是,如果您有没有经验的测试人员,您最好将他们与更有经验的测试人员配对,并让他们指导新手测试人员完成章程。不过,这有点离题了。

我刚刚开始使用基于会话的测试来代替脚本测试用例。到目前为止,我的章程相当简单:

  • 要测试的功能区域,以及我计划如何测试。(功能,性能..)
  • 自上次会议以来对该区域的任何更改。(是否已纠正错误?它会影响其他领域吗?)
  • 限制,即。我知道一个仍在进行中的部分,因此该区域中的任何内容都可能不完整,并且应该考虑到这一点来评估错误。

以这种方式构建我的章程使我能够跟踪可能发生的任何面包屑线索,同时还以“用户故事”的方式指导我。我比以前使用这种方法更详细地记录了我实际所做的事情

我喜欢绘制我计划测试的系统(或系统的方面)的实体和关系。

有时当我被一个问题困住时,向其他人解释它的行为会让我变得不被困住。对方可能不需要说一句话;正是我提出了导致解决方案显现出来的问题。同样,图表可以揭示新的测试想法。

根据问题的需求,我们可以阅读这篇非常有用的文章。“探索性测试,更好的测试覆盖率指南”,它可以回答您的疑问。