做平臺性的測試工具,通常涉及到各個角色,接觸多的是測試工程師和開發工程師。

  和用戶溝通

  普通用戶抱怨質疑多,方案建議少;但是測試工具的大部分用戶是測試工程師和開發工程師。

  他們一般都明白自己所需并具備清楚表達的能力,有明確的價值目標,有良好的方向感和情境感,有些自己本身獨立開發過的工具,所以在整個工具開發的生命周期中,他們能承擔更多角色,參與更多過程。

  測試人員提前介入需求,甚至擔任某些模塊的PD,參與到產品開發中來,對工具的順利推廣也很有幫助。畢竟,是自個兒親生的。這批同學是工具早的用戶,他們的工作模式能影響和帶動一批用戶。

  對設計師的要求

  測試工具和一般互聯網產品有所不同。

  傳統頁面以導航和內容為主,測試工具內容并不復雜,重功能和交互。

  區別于導航和內容的羅列, 作為管理和幫助性工具,一個頁面通常會集中很多功能;工具所爭取減少的每一步操作都是在節約工程師的時間,出于工作效率考慮,需要更豐富便捷的交互操作。

  在實際開發過程中,大部分前端問題也是在交互方面。從用戶反饋來看,用戶對功能性和交互性的要求遠遠遠遠高于界面樣式。

  這要求設計師必須對系統需求有所了解,包括業務流程、理解專業術語和每一步操作的目的,否則是盲人摸象。

  不懂測試的設計師很難做出符合期望的界面設計。一般這類工具的設計師角色都是由測試或者開發本身承擔。缺點是產出的界面稍遜美觀。不過根據我的經驗,人民群眾其實是不畏懼界面丑陋的,真正能使用的工具才能長久生存下來。

  和開發溝通

  關于工具交互,用戶有很多的建議和想法,不過終落實還是到開發頭上。可惜的是,好的交互一般開發起來都挺費事兒。大家知道,想把用戶體驗做到,讓用戶輕松,開發要“受罪”,要額外做很多在他們看來價值不大的細節工作。程序員有一個信念,這個世界上,沒有代碼實現不了的事情。如果他說無法實現,一定是他不想。設計師對于開發工作所用到的知識有所涉獵,不用成為行家,但至少“略懂略懂”,好有自己動手的能力,能預估開發投入。這樣,才能與開發工程師建立平等對話,提出的需求和設計才不會被人一略而過。《越光寶盒》里面諸葛亮不是有句臺詞么,什么都懂一點,生活才能更多彩。

  說著容易,實際很難,很多事除非開發自己想明白,勸是沒用的。團隊里好有個能一語定乾坤的權威人物,實在和開發溝通不了了,找他定奪。

  工具開發的過程中,在很多情況下,開發本身是PD,會傾向于簡化項目,盡量少做、做自己熟悉的,使得項目順利完成,并且bug很少,做出來的也許體驗不好,但是“夠用”。

  其實協同,是你去協同別人,而不是別人來協同你。主動一點,獲得更多。