Tester該怎麼自救？

想像一下，自己是個浮潛愛好者。

趁著四月的好天氣，和七個同好去鵝鑾鼻南方七星岩浮潛，想要探尋海底沈船。

一潛下去卻發現海面水流和海底水流相反，當你發現不對勁想上升減壓時，卻遭遇強勁的北上洋流，想往岸邊游，卻發現自己被夾在詭譎多變的沿岸流與黑潮強勁洋流間，只能隨波逐流。

這個時候，你會怎麼做呢？

這個情況

對一般人而言或許不大可能遇到這種狀況，但在職場上這種狀況卻屢見不鮮。

我上個月去上海出差，主要是去客戶那邊測試我們要交付的產品。就在我執行自己測試個案的時候，我聽到一旁的客戶公司測試部門的員工（以下簡稱：客戶員工）之間的對話，其實他們遇到的就是以下狀況：

組織僅提供了少數/有限的資訊：

• 有User Guide，但裏面的內容不完整，也不足以幫助測試團隊了解產品。
• 有Test Case，但步驟不清楚，有些步驟甚至只有一句話帶過，並沒有提供細部的測試資訊。
• Tester到職後沒有訓練的過程，也沒有訓練教材。

團隊的部份：

• 欠缺知識庫，所以，組織並沒有辦法提供 Tester 所需的產品相關資訊。
• 欠缺知識分享/管理的流程，所以 Tester 只能靠自己從實際的測試活動中，累積和產品相關的經驗與資訊。

綜合以上的情況後，就變成 Tester 到職後才發現自己是前面說的浮上水面的浮潛客，得要自己面對一連串的現實生存問題：

• 不知道該如何上手測試工作
• 不知道該如何測試產品
• 不知道該如何了解產品

浮潛客的自救措施

在真實案例中，這些浮潛客因應現況，實施了一連串的自救對策，以應付各種的威脅：

• 恐懼
  8名潛水客始終團結在一起，互相打氣。打開螢光浮力袋，以及將潛水衣充氣漂浮，以延長存活的時間。並打開像相機閃光燈、強力手電筒一樣能在黑暗中發光的東西。
• 缺少方向感
  在漂流中看到台東的綠島，目視距離大約10公里，但發現黑潮的阻隔加上強勁的北向流速，根本無法登島，所以決定捨近求遠，西行朝30多公里外的台灣陸地踢水前進。
• 失溫與疲累
  潛水扣環扣住彼此，一人划水時、另一人就休息，並互相提醒不要睡太久，以免失溫。
• 脫水
  彼此互相幫助抬腿，然後用蛙鏡接尿液喝。據潛客事後表示：「感覺尿喝起來竟是如此甜美與珍貴，恨不得自己能多尿一點。」
• 低求生機率
  考量體力問題，分組獲救機率比較大。先是4人一組，因洋流關係再變成2人一組，最後由體力最好的教練，脫隊上岸求救，使所有潛水客獲救。

Tester的自救措施

我所提的解決方案其實也只有兩點：

• 停止抱怨
• 知識分享

我實在也想不出在如此「蠻荒」的情況下，只靠Tester本身，還能做其他更有效改善現況的自救活動。

當然，如果讀著有其他更好的解決方案，也歡迎大家分享。

第一步：停止抱怨

「存在就是合理」是我每次看到每個不合理狀況的解釋，這自然包括了客戶這間外資企業。

完美的公司並不存存，現實狀況下，公司不是薪水太少、就是管理待改善、再不然就是福利差、或欠缺員工訓練的機會，若非如此，Google也不會有人離職呀！

因此，只要是人組織的組織，就會有人的問題，所以才會有這麼多的管理專家。說到底，他們解決的其實就是人的問題。

但以一個員工的角度來看，就必須認同問題存在的必要性。

一直抱怨，是不能解決事情的。只有停止抱怨、接受現況，才能讓自己認清現況，並提出自己的改善之道。

解決內在的問題，這點才是最難的一點！

第二步：建立知識分享的小組織

是我提出的「知識分享」的第一步，就是找一群不抱怨、認同現況、願意分享個人看法、並願意從自己做起的夥伴。

其實，客戶員工的情況，並不比這些潛客好多少：如果再不自力救濟，就不會有好的表現；沒有好的表現，就不會有更好的報酬；沒有更好的報酬，並不會讓你想長久的待在一間公司；在一間公司待不長，並不會學到更多的東西；沒有學會更多的東西，是不大可能在同一領域就長久立足。

在現實情況中，當然不是所有的Tester都認同這個情況，然後意識到必須與其他人合作才能活下去；也不是所有的Tester在認同這個狀況後，都願意與其他人合作；更不是所有的Tester，在認同情況也意識到必須與其他人合作後，就願意真的與其他人分享寶貴的生存資源，這些限制，正是在現實環境中很難執行此活動的原因。

不過，不用擔心，即使只有一人，以下的活動還是能夠繼續展開。

第三步：釐清/建立文件化的知識

人的問題解決後，接著就須要釐清那一些知識對了解產品或執行測試有用？值得花資源蒐集。

我給客戶員工舉的例子，是我針對目前專案所做的一本生存手冊，其中包含了一些重覆使用的命令、不常用到的重要內容。這本手冊，讓我能一直參考，不用花時間到處翻找資料。

然後，只要有新到職的同事我就會分享給他們，讓他們有機會去認識產品、並知道如何測試產品。

我在另一間公司的情況，是直接買實用的工具書，然後摘錄書中相關的資訊，以求馬上能應用於工作中。

第四步：建立知識分享的流程

這點其實是最重要的一點。

實際的操作，有的公司是放在WIKI內，有的公司是放在Word檔或PPT檔然後存在網路資料匣中。其實不論是放在那裏，切記要放在能方便取用的地方，才能隨手取得，隨時觀看，隨時更新。

我建議客戶員工每周聚會一次，然後每個人花點時間分享當周的收獲，然後有組織地將這些知識文件化，接著就能在下周使用到這些新資訊。

只要重覆這些對的流程，參與的人在一段時間後，就自然能有收獲，更能增加生存的機會。

第五步：改進知識分享的流程

如果發現目前累積的知識，不敷使用時，就可以應用PDCA的概念，不斷修正目前的流程。

可以改善第二步、讓更能提出知識的人進入這個小團體；或是改善第三步、重新釐清應加入的知識；或是改善第四步、修正目前知識分享的流程。

只有知道不足，才會知道要如何改善。

小結

以上內容是我從「Tester」的角度，提出個人能力所及的範圍內所提出的改善之道。

當然，最有效的方式是從組織的政策、資源、流程去「改進」測試部門的不足。但倘若測試部門就是欠缺這些重要的流程/活動、單位主管也不知道/不願意做這些活動時，就可以從發揮個人影響力的角度，來「改善」組織的不足。

雖然「改善」的效果雖然比不上「改進」，但卻足以拉開與其他人的距離了。

我和大家分享一個故事：一架飛機在非洲失事，只有一個日本人和美國人存活下來、但是身上的衣服都破了，鞋子也掉了。這時來了一隻獅子要吃他們。美國人拔腿就跑，但日本人卻蹲下來把鞋子穿好。美國人問日本人為什麼不趕快跑？

日本人說，「等我把鞋子穿好後，不用跑得比獅子快，只要跑得比你快就好了。」

後記1

在本文中，因為使用「知識分享」一詞，所以後面都以「知識」來稱呼這些應被稱作「資訊」的東西。

後記2

我前面說自己會和同事分享這份文件，因為我不是這個部門的頭，所以他們是否真的認真去看裏面的內容，老實說我一點也不在乎。

不過，倘若這些員工是我的手下，我可就不會這麼輕易地放過他們。

首先我會直接告訴他們「知識分享」，是我這個單位內很重要的一件事，也是年度考績的一個重要指標，而且會是逐月考核的重要項目。

每個成員，在進入這個部門得到別人分享的心得時，就有義務分享自己工作的心得。

• 自由時報-《海漂百里 8潛水客全獲救》

Jose’s Google+ profile