简单经济的可用性测试上手指南

 读过《Don’t Make Me Think》的人肯定记得，作者在其中提到了简单的可用性测试。不过用个摄像机什么的，似乎不太适合我们这边的情况，在国内的中小型企业，实际的尝试和运用中，还是需要不少变通的。今天就来谈谈我在实践中得出的一些经验。

如果：

        你所在的公司刚开始推行UCD，一切都刚起步；

        没有固定的人手，没有很多的资源，测试研究的时间和经济成本非常局限；

        你看了不少有关的书和文章，但实际开始做的时候还是觉得有不少困惑

        那么，希望这篇文章可以帮助你。
　

时间
测试的时机

        理想地说，可用性测试尽早开始越好，也应该是产品开发的一环，可以有一个迭代的过程。但是对于初次的尝试来说，不一定能够做到：也许你的Boss不希望把“半成品”拿出来给人看，也许你们的开发进度紧迫插不进这样的时间，但是也不必放弃，晚测试总比不测试好，实在不行就把发现的问题放到下个版本去修改。亡羊补牢，为时未晚。

        当你的同事和上司看到了可用性测试的价值后，你做测试也慢慢上手了，就能争取到加入开发环节的机会、迭代测试和开发的机会。或者你的产品频繁有少量改动的更新，这样子测试问题也不大。

        你需要的，只是抽出下面提到的一些时间。

准备时间

        测试前，你可能需要在一两周的工作时间穿插可用性测试的准备工作。若是刚开始在公司尝试可用性测试，你应该写一份简单的测试计划——告诉你的Boss你要做什么事情、也帮助自己规划做测试的一系列工作。

        然后也许你需要申请一些资源，空间、硬件、人员协助等等～

        Check一下这次要测试的功能，设计一下测试的任务。如果是第一次测试，心里过一下整个测试的过程，开始-测试时的引导-结束，有机会做次导测的话会让你更有信心。

        还有就是招募受测。这个根据你招募的方法需要的时间不同，具体的招募请见下面的部分。

测试时间

        准备好了，和受测也约好时间，就可以开始测试了。

        你的受测很可能是上班族，这也就意味着测试会安排在非工作时间，比如晚上、周末。就算你很经济，用的是同事，也可能因为他们工作繁忙需要一起占用午休时间或者下班后多留一会儿。>_<真是辛苦，测试难免会需要你加班。而唯一的好处就是，如果你是在本职工作之余做这件事，对原先工作的进度影响就没那么大了。

分析&结果分享时间

        测试结束之后，整理下你的记录(如果有条件录像的话，还要回看录像)，分析归纳写一份测试报告，写下发现的问题，附上些截图或者关键录像片段。报告不必弄得很详细，目的是为了把测试发现的问题让同事了解。个人觉得比较好的是PPT，不必很多文字，可以现场讲解问题的具体情况和背后的原因、还可以大家一起讨论修改的方案。如果没时间做presentation，给同事看文档，写简单一些，挑重要的写。

       

原文转自：http://www.ltesting.net