qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

软件测试工具设计中的协作

 做平台性的测试工具,通常涉及到各个角色,接触最多的就是测试工程师和开发工程师。

  和用户沟通

  普通用户抱怨质疑多,方案建议少;但是测试工具的大部分用户是测试工程师和开发工程师。

  他们一般都明白自己所需并具备清楚表达的能力,有明确的价值目标,有良好的方向感和情境感,有些自己本身就独立开发过优秀的工具,所以在整个工具开发的生命周期中,他们能承担更多角色,参与更多过程。

  测试人员提前介入需求,甚至担任某些模块的PD,参与到产品开发中来,对工具的顺利推广也很有帮助。毕竟,是自个儿亲生的。这批同学是工具最早的用户,他们的工作模式能影响和带动一批用户。

  对设计师的要求

  测试工具和一般互联网产品有所不同。

  传统页面以导航和内容为主,测试工具内容并不复杂,重功能和交互。

  区别于导航和内容的罗列, 作为管理和帮助性工具,一个页面通常会集中很多功能;工具所争取减少的每一步操作都是在节约工程师的时间,出于工作效率考虑,需要更丰富便捷的交互操作。

  在实际开发过程中,大部分前端问题也是在交互方面。从用户反馈来看,用户对功能性和交互性的要求远远远远高于界面样式。

  这就要求设计师必须对系统需求有所了解,包括业务流程、理解专业术语和每一步操作的目的,否则就是盲人摸象。

  不懂测试的设计师很难做出符合期望的界面设计。一般这类工具的设计师角色都是由测试或者开发本身承担。缺点就是产出的界面稍逊美观。不过根据我的经验,人民群众其实是不畏惧界面丑陋的,真正能使用的工具才能长久生存下来。

  和开发沟通

   关于工具交互,用户有很多优秀的建议和想法,不过最终落实还是到开发头上。可惜的是,好的交互一般开发起来都挺费事儿。大家知道,想把用户体验做到极 致,让用户轻松,开发就要“受罪”,要额外做很多在他们看来价值不大的细节工作。程序员有一个信念,这个世界上,没有代码实现不了的事情。如果他说无法实 现,一定是他不想。设计师对于开发工作所用到的知识有所涉猎,不用成为行家,但至少“略懂略懂”,最好有自己动手的能力,能预估开发投入。这样,才能与开 发工程师建立平等对话,提出的需求和设计才不会被人一略而过。《越光宝盒》里面诸葛亮不是有句台词么,什么都懂一点,生活才能更多彩。

  说着容易,实际很难,很多事除非开发自己想明白,劝是没用的。团队里最好有个能一语定乾坤的权威人物,实在和开发沟通不了了,找他定夺。

  工具开发的过程中,在很多情况下,开发本身就是PD,会倾向于简化项目,尽量少做、做自己熟悉的,使得项目顺利完成,并且bug很少,做出来的也许体验不好,但是绝对“够用”。

  其实协同,是你去协同别人,而不是别人来协同你。主动一点,获得更多。

posted on 2012-05-07 09:49 顺其自然EVO 阅读(137) 评论(0)  编辑  收藏 所属分类: 测试学习专栏


只有注册用户登录后才能发表评论。


网站导航:
 
<2012年5月>
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

导航

统计

常用链接

留言簿(54)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜