导读:今天让我们聊聊到底探索式测试应该怎么来执行呢?
01
基于测程的测试管理
对于探索式测试的具体执行层面,我们会采用一种称之为Session-Based Testing management(简称SBTM)的方法来进行测试。关于SBTM术语的中文翻译,史亮、高翔两位老师在他们的著作《探索式测试实践之路》中把它翻译成“基于测程的测试管理”。至于为什么不把它翻译成“基于会话的测试管理”的原因在书上也特别做了注释,有兴趣的朋友可以去查阅。
SBTM把整个测试工作分成了多个Session来完成,每个Session包含了下面几个要点:
下图是关于SBTM的一个简单的测试流程,供各位读者参考:
02
实例介绍探索式测试SBTM如何开展
接下来我们以一个酒店入住登记的场景作为例子来看看SBTM是怎么进行的,场景如下:
某酒店针对其酒店APP系统的旅客入住自助登记模块进行优化更新,针对不同级别的会员,在办理入住登记的时候会有相应的福利。例如:针对金卡会员预定了普通房,当豪华房型有空房的时候,可以自动升级到豪华房型;而要是金卡权益过期的会员,则不会有升级的福利。
我们来看看如何开展SBTM进行探索式测试。
1. 计划步骤
在计划的过程中,我们需要确定测试的目标,分解测试的Session,准备安排相关的测试资源等。
那么什么时候开始创建Session呢?可以在Sprint计划时、也可以在开发过程中或用户故事准备好测试时。具体的时间没有明确的规定,但是我们建议尽可能早地进行一些初始计划。
可以尽早创建和准备进行探索性测试的Session,然后在测试开始之前对现有测试Session进行重新review——是否需要额外增加的Session?指定的Session仍然和测试目标相关吗?
一个Session包括:
您可以马上将新的Session分配给测试人员,但是建议在故事进入测试阶段时再分配测试人员,这样可以保证团队成员分配的灵活性。
关于Charter
一个好的Session Charter并不用那么精确,它本质上是一个单一的测试场景,但它也不应该太宽泛和模糊,以至于Session没办法在我们指定的时间盒内完成。
当你刚接触SBTM时,你可能很难知道要计划什么Session,试试这个简单的技巧——识别对用户故事和被测应用中重要且相关的风险,并分别为这些风险创建Session:
需要考虑的基本风险列表包括:性能、可靠性、可用性、安全性、可伸缩性、可安装性(软件安装过程)和兼容性等。请记住,这个列表只是Session Charter思考的一部分。
所以针对上面的场景,我们定义一个Session Charter的例子如下:
“通过APP入住自助登记功能探索住客在自动办理入住过程中的用户体验和接收到相关的房间升级福利,自助办理入住过程的体验需要和前台办理入住的体验一样好。”
2. 执行步骤
开始一个Session
计划和跟踪你在执行Session过程中的测试工作非常重要,因此一个Session可以分为三个状态:开始、处理中和结束。这三个状态是不是让您联想到了看板的泳道?是的,我们建议使用Jira和看板进行Session状态的监控,使得session状态透明可见。
我们可以在Jira中把Session当成是一个issue type,把Charter和Time Box等设置成属性字段,并可以设置“开始”、“处理中”和“结束”三个流程状态。
我们规定在Session是“开始”状态时编辑Charter,但是不能记录任何Notes或缺陷。只有在“处理中”的状态时才可以。“开始”状态是确保我们去思考测试想法的过程。
如果发现了缺陷,我们需要在Jira中报告缺陷。登记缺陷一般有两个入口:一个在Session流程中登记;一个是在Jira的主菜单登记。从Session中报告缺陷比在Jira中创建一个常规缺陷有很多优势:
Taking Notes(记笔记)
很多测试可能会在几个小时内进行,所以在Session期间做笔记是很重要的。特别是在Session结束时,您需要编写简短的Session结果摘要,并向产品所有者或团队简要说明。
有了笔记,写一份准确的总结就容易多了,也意味着你不会忘记重要的事项。在必须提交证据的监管环境中,Session记录和附件也可以作为证据。
如果在Session中有各种不同的笔记类型需要记录,我们可以为每个笔记打上不同的Lable标签:
在这个场景中,比如我们增加一条Notes,并且打上”Idea“标签:
小技巧:
如果你发现自己花了很多时间在charter上,想要回到正轨,那么记录当前这个转移,并创建一个新的Charter。Session期间的观察和发现常常为今后的Session提供很好的Charter。
停止一个Session
当您完成测试后,剩下要做的就是选择“结束”状态以结束该Session。完成此操作后,设置jira将提示用户编写Session的简短摘要、对已测试的工作质量和会话覆盖率进行评级,并可选地记录他们的时间是如何使用的。参照如下图所示:
Summary只是Session结果的一个高级视图,应该进行一个完整的汇报以最大化探索式测试的价值。
3. Debriefing步骤
在测试过程中会捕获大量的信息,这些信息需要在一个紧凑且简洁的节奏中传递给团队才能发挥作用,这就是汇报的作用所在。汇报不只是与团队共享信息,还使Session和测试工作对团队负责,并提供一个机会来评审和改进Session的执行方式。
Debrief由包括负责总结会议进展情况、发现关键信息以及其它人对质量看法的测试人员、以及产品负责人、Scrum Master(如果你使用Scrum)和其他团队成员组成。
汇报期间讨论的主要领域如下:
请注意,所有这些信息都是在Session中通过记录Notes而捕获的,这些Notes使执行汇报变得更容易。
Debriefing输出
在Session Debriefing结束时,通常会决定一系列的行动。这可能需要开发人员在Story或缺陷上做更多的工作,特别是在发现缺陷或之前未知的风险被识别的情况下。如果产品所有者或团队发现仍然存在风险或者Session覆盖率很低,那么Session Debriefing的一个结果可能是创建另一个Session。
Session改进
让测试人员参与Debriefing通常是一个好主意,她或他可以从会议中回顾执行的测试想法,并为备选的测试想法和技术提供建议,以供将来考虑。您可以将此视为对测试Session进行回顾。