|
在可用性测试中，最主要的两个角色，一个是受测(TestParticipant)，另一个是测试员(TestFacilitator)。这回小兔来说说测试员(TestFacilitator)在可用性测试时应该做些什么、说些什么。之前有翻译过TestFacilitatorGuide（可用性测试开始前），那么开始之后该如何呢？这里有一篇文章，拿来作为例子说说，小兔也和自己的做法对照比较一下，好借鉴改善。
WAISiteUsabilityTestingQuestions
文章包括了四个部分：Pre-testQuestions（测试前问题）、ParticipantTasks（受测任务）、Post-testInterview（测试后访谈）和Post-testSurvey（测试后问卷）。这是WAI（WebAccessibilityInitiative）网站可用性测试，测试员(Facilitator)在测试时提的问题和任务的设计。
Pre-testQuestions（测试前问题）测试前的问题是用来了解受测的，WAI的这个例子里，可以看到问题关于受测对于可及性(WAI的主要内容)的了解、平时访问的相关站点、阅读习惯、工作背景等，以及大概的心智模型。了解受测，才能在之后明白受测的行为，便于进一步分析产品的可用性问题。我们在招募受测时也会做一些甄选，但是都比较简单，而测试前提一些问题可以了解得更真实具体些。根据产品的特性，我们可以设计不同的问题。另外，小兔把测试前的问题作为“暖场”，虽然准备问题提纲但并不严格照问。比如一次一个受测是QQ联系的，我就从他的六位QQ号聊起，询问他的网龄等等~有时甚至可以闲聊两句，让受测放松了，会表现得更自然，也比较容易ThinkAloud
ParticipantTasks（受测任务）这当然是测试的主要部分。WAI的这个例子里比较特殊的是Task1和Task2。Task1测的是网站的首页，类似的一些提问方法曾经在UPA也学到过。首页是网站给用户第一印象的关键之处，通过Task1的这几个问题可以了解到受测对于网站的大概认知；而基于WEB的浏览往往不一定居于特定的任务，所以Task2是给用户自由浏览的时间。应该说，大部分时候我们浏览网站可能也是没有什么目的的，小兔也曾愁过测试任务的问题，没想到和WAI一样的做法呢:)之后的每个任务都设计了一个场景，让用户找寻相应的信息。意料之外的是之后的任务还有8个之多，我依然没有明白为何需要这样的数量，如果某个任务的场景和受测背景不符咋办呢？难道是8个任务里选做的？@_@
Post-testInterview（测试后访谈）如果说测试的任务是观察受测行为的话，测试后的访谈就是了解用户的想法。经过对网站的一番体验之后，受测对网站也有了实际的了解，小兔也很喜欢在测试后问这些问题，尤其是在产品早期进行可用性测试、有较大改动空间的时候，不妨问一些开放式的问题，对于设计的改进有不错的参考作用。
Post-testSurvey（测试后问卷）这个问卷有些类似SUS，但我们可以看到不止是SUS的问题，除了评价网站的可用性之外，有一些可以用来验证是否达到我们的设计目标。比起访谈的好处是，这些的结果可以量化。不过对于小规模的可用性测试来说，这些数据缺乏科学性，仅用来参考。
|