如何做好不擅長的測試任務

• 2020 年 3 月 8 日
• 筆記

  測試任務的多樣性、組織人員流動以及人員技能備份、測試工作節奏等因素決定了一個測試人員不可能一直做着自己熟悉領域內的測試工作任務。一個測試人員需要經常性的接手完成你不太熟悉領域、不擅長的測試任務，如何在任務要求的截止時間內有質量的完成是一個硬實力和軟實力結合的技術活。我也飽受此折磨，所以想聊下這個話題。算是吐槽吧。

  通常來說，大部分任務到某個測試人員身上都是任務驅動的。可能當測試任務來的時候，熟悉該項測試工作的A同學正在投入某項緊急任務中無法投入，領導自然就會將這個測試工作安排到不熟悉或者完全不懂的B同學身上。你說B同學可以以自己不熟悉該任務拒絕嗎？拒絕是不太可能的。測試工作中有太多類似的測試任務了。每個人都拒絕，活就沒法幹了。每個人都永遠干自己熟悉的測試任務，人員技能也無法備份。。這些因素是後話不討論。通常來說，這種不太擅長的任務你還是得接手，不僅要接手，也不要有太多的情緒，別活還得干還讓領導覺得你挑肥揀瘦就得不償失了。想辦法怎麼在規定時間內保證質量完成是你要考慮的問題。有事別怕事，下來想轍就是了。。心情很重要。

  一個不擅長的任務接了又得把它干好，這是個技術活。這時候每個人處理的方式就不一樣了。首先，接收測試任務的時候一定要先了解清楚任務的背景、任務完成時間、任務相關責任人。我就以我自己和身邊所看到的同事舉一兩個例子。從我自己來說，這種任務沒啥毛病，但是我不喜歡那種要求時間很短又很不擅長的測試任務。一個是本來就不熟悉風險無法評估、質量不可控，第二個時間緊急壓力大容易出問題。但是通常這些都不是理由，還是得去完成並且保證不出問題。

  好，開始幹活。在了解清楚任務的背景、任務完成時間、任務相關責任人，下來就需要了解測試任務本身內容了。只有了解了測試內容，你才能相對合理評估測試工作量、識別測試風險、哪些需要提前求助、是否需要提前上升。我的方法是比較喜歡自己先琢磨這些這些測試內容，去找資料學習，在基本了解測試內容之後再去找之前熟悉這一塊的內容去把風險點搞清楚。我習慣這種做法但是這種做法其實在有限的時間下是不合理的。因為沒有那麼多的時間允許你去慢慢了解。這樣有一個明顯問題，就是讓上面感知你的工作進展很慢，實際上應該是拉着之前搞過這一塊內容同事給你講解這一方面的內容。事後發現這確實是一個有效的辦法，但是我並不是很習慣動不動就拉着別人去給你講上半天這種東西，在當前工作強度下，每個人的工作節奏都很快，佔用了這半天時間也就意味着別人最近又得加班了。。可能是我自己想多了。但經常礙於deadline，又只能強拉。。所以這是我不喜歡的原因。但是我看到同事的方法就和我相對反着，他的習慣是先直接拉着別人對任務。讓別人講解也一樣能把事情搞定下去。我不太喜歡這樣的方式，所以部分時候有限時間下做這些不擅長的測試任務是你逆着自己的習慣在做，有時候也會心煩這些事情。

  既然知道問題所在，任務要做也要讓自己心情保持好一點。不然會經常感覺在受苦。。太苦逼了。需要改變一下自己。從個人層面來說，需要自己基本過一下測試內容，然後在規定時間內（比如不超過30分鐘）讓之前搞過的同事講解一下重點、可能的風險點、之前遇到哪些問題需要提前去問、去了解的。這樣基本框架就有了。下來就自己好好了解一下內容，有風險的提前上報、有疑問點的記錄後面集中拉一下釋疑。另外，每天及時反饋進展、反饋阻塞點、風險點，讓領導知道情況。另外，從組織層面來說，如果是一個後期較長的測試任務或者外地出差的測試任務（比如半個月一個月），需要安排好測試任務相關責任人，明確問題接口責任主體和職責，遇到問題可以讓測試人員及時找到求助對象，及時推動問題解決。不然所有問題讓測試人員都自己臨時去協調，可能找不到也可能找到了別人沒時間支撐拒絕。會讓測試人員很心累，次數多了，就容易出現人員穩定性問題。

  另外，測試任務完成後，自己一定要注意測試經驗積累，多寫一些經驗文檔，包括環境操作、問題FAQ、測試技巧、業務邏輯、測試問題以及解決方案等等。不要覺得不重要，一個很小的問題FAQ可能就會導致後續的人阻塞很長時間。重視這些經驗文檔積累，對自己、對組織都是一個很重要的財富。想想自己這麼痛苦搞着這件事，後續同事繼續搞這些事情的時候使用這些文檔就可以起到助力作用。

   對我自己來說，我一般還是比較習慣針對自己不熟悉的領域、技術點寫一些經驗文檔共享，這樣起碼可以保證在完成一件不擅長的任務後，有一點經驗積累。下一次就相對擅長了，也可以幫助到下一個干這任務的同事。如果是你，你在領導分配給你不擅長的測試任務時候會有什麼想法？有什麼好的經驗可以分享的可以聊聊。建議別輕易拒絕。。