我们现在正处于项目的深渊,时间紧迫(但合理).我们的一般策略是完成一个强大的测试版,将其发布用于测试,并从我们的测试人员那里获得反馈.
很多时候,我们受到了一些小事情的影响,这些事情会导致长时间,耗时的讨论.它们都归结为一件事:虽然我们知道我们需要什么功能,但我们在处理细节方面遇到了麻烦,例如"这条消息应该去哪里"和"他们是否需要立即反馈,或者它会破坏它们的流量,所以我们应该推迟'?
这些都是我们的测试人员应该抓住的东西,但是
a)像这样的每个"低优先级"错误都会从关键问题中消耗时间
b)我们希望拥有尽可能强大的产品
和
c)即使是最好的测试组也会不时地错过任何东西.
我们使用我们的产品,并且我们知道我们的用户如何使用旧版本......但是当我们尝试使用新版本时,我们都不知道如何像用户一样思考(具有重要的图形以及潜在的变化).
编辑 - 更多背景:
我们正在编写一个广泛分布的用户群使用的Web应用程序.我们的应用程序是他们工作的重要组成部分,但不是最大的(当然,当它不起作用时,我们只对它们很重要).让实际用户使用我们的产品很困难,因为我们在地理上远离最近的用户(我们在俄亥俄州,我认为距离我们最近的位置是3个多小时).
我们能得到的最接近的是我们的客户服务团队(他们真的很有帮助),但他们并不像用户那样思考.他们也是我们的测试人员(当他们知道任何他们找不到的任何可能意味着电话数量大幅上升时,它确实激励他们发现错误).本周大部分时间我们有三位(总共约12位)客户服务代表在这里进行一些初步测试......他们也参与了讨论.
看着有人使用该应用程序对我来说是一个巨大的好处.可能是某人并不完全熟悉它.
了解他们如何尝试导航,他们如何尝试输入信息或调整窗口大小.在创建/运行应用程序后,我们认为这是理所当然的.
用户总是会尝试做你从未预料到的事情,并且观察他们的行动可能会揭示你如何改变可能看似微不足道的东西,但确实会对他们产生重大影响.
阅读不要让我思考.
一般来说,你不能.没有任何方法可以关闭大脑中的"程序员"部分并像用户一样思考.
你是对的(c),测试组并不一定能抓住所有的bug.但是你能做的最好的事情就是让一个由真实,诚实到善的最终用户组成的测试小组,并重视他们的反馈.从其一般性评论中得出进一步的结论
如果您想知道用户将如何看待您的系统,那么您可以获得的最接近的是真实用户的可用性测试.其他一切只是启发式和经验,也会出错.没有无错产品这样的东西,但你应该能够通过可用性测试获得"强大"的产品.
购买便宜,易于使用的摄像机,并使用该应用程序记录您的测试人员.更好的是,让一些人不熟悉应用程序.使用它并录制它们.这是相对便宜的,你会惊讶它会突出.