iT邦幫忙

第 12 屆 iT 邦幫忙鐵人賽

DAY 28
2
自我挑戰組

從 RD 到 PM 的奇妙旅程 - 陪伴我成長的心法與工具整理集系列 第 28

[Day28] 溝通之術 - 測試工程師篇

這是鐵人賽接近尾聲的倒數第 3 篇~今天就來講講跟測試工程師的溝通之術吧!

前言

原本是個坐在位置上,每天打開 Jira 檢視今日任務,做完就下班的,害羞內向閉俗安卓工程師,因緣際會下,開啟了與人溝通的旅途,以下會標示一些基本素質給大家參考,大多都是個人主觀意見,請斟酌使用:

  • 契機:因為實作出的東西跟測試工程師預計的功能有所落差,所以需要透過討論了解問題。另外就是有些驗證做得不夠完整,所以也是需要跟團隊討論怎麼處理這些細節的部分。
  • 跟測試工程師直接溝通的時間:一年多。

以 RD 身份和測試工程師合作專案

當身為 Android 工程師的時候,其實超級擔心測試工程師跑來跟我說話 XD,最常有問題的會是跟使用者互動的細節沒處理好。後來寫後端時,有時也很粗心地沒把錯誤狀態劃分清楚,而細心的測試工程師就會告訴我這些細節。當我再去做其他 API 時,也會先把這些細節拿出來檢查。例如:如果回傳空值要怎麼處理?、如果遇到重複名稱要怎麼處理?是不是應該要過濾字串等等。

以 PM 身份和測試工程師合作專案

由於有前面的一些經驗,會在初期就先將跟介面有關的測試標準,跟設計師還有測試工程師一起討論。目前還在摸索的部分是如何才能將驗收標準詳細地列出來。

後記

測試在我身為 RD 時提出的問題,也成為我在身為 PM 時,會去考慮的部分。到後來甚至會很驚嘆測試總能找到一些身為 RD 的盲點。如果操作流程覺得不順暢,也可以提供給設計師參考,可以去優化現有的流程。

今天講完了測試工程師篇,明天輪到誰呢?嘿嘿,那麼,明天見啦!


上一篇
[Day27] 溝通之術 - 開發工程師篇
下一篇
[Day29] 溝通之術 - 老闆篇
系列文
從 RD 到 PM 的奇妙旅程 - 陪伴我成長的心法與工具整理集30

尚未有邦友留言

立即登入留言