想像一下自己是個浮潛愛好者。
趁著四月的好天氣，和七個浮潛同好去鵝鑾鼻南方七星岩浮潛，想要探尋海底沈船。
一潛下去先發現海面水流和海底水流相反，當你發現不對勁想上升減壓時，卻遭遇強勁的北上洋流。
你想往岸邊游，卻發現自己被夾在詭譎多變的沿岸流與黑潮強勁洋流間，只能隨波逐流。
這個時候，你會怎麼做呢？
SW Tester 的常見遭遇
對一般人而言或許不大可能遇到這種狀況，但對 SW Tester 來說，類似的狀況卻屢見不鮮。
我上個月去上海出差，主要是去客戶那邊測試我們要交付的產品。就在我執行自己測試個案的時候，聽到一旁的客戶公司測試部門的員工（以下簡稱：客戶員工）之間的對話，其實他們遇到的就是以下狀況：
組織僅提供了少數/有限的資訊：
- 有User Guide，但裏面的內容不完整，也不足以幫助測試團隊了解產品。
- 有Test Case，但步驟不清楚，有些步驟甚至只有一句話帶過，並沒有提供細部的測試資訊。
- SW Tester到職後沒有訓練的過程，也沒有訓練教材。
- 欠缺知識庫，所以，組織並沒有辦法提供 SW Tester 所需的產品相關資訊。
- 欠缺知識分享/管理的流程，所以 SW Tester 只能靠自己從實際的測試活動中，累積和產品相關的經驗與資訊。
- 不知道該如何了解產品
- 不知道該如何上手測試工作
- 不知道該如何測試產品
浮潛客的自救措施
在這個真實案例中，這些浮潛客因應現況，實施了一連串的自救對策，以應付隨之而來各種的威脅：
- 恐懼
8名潛水客始終團結在一起，互相打氣。打開螢光浮力袋，以及將潛水衣充氣漂浮，以延長存活的時間。並打開像相機閃光燈、強力手電筒一樣能在黑暗中發光的東西。 - 缺少方向感
在漂流中看到台東的綠島，目視距離大約10公里，但發現黑潮的阻隔加上強勁的北向流速，根本無法登島，所以決定捨近求遠，西行朝30多公里外的台灣陸地踢水前進。 - 失溫與疲累
潛水扣環扣住彼此，一人划水時、另一人就休息，並互相提醒不要睡太久，以免失溫。 - 脫水
彼此互相幫助抬腿，然後用蛙鏡接尿液喝。據潛客事後表示：「感覺尿喝起來竟是如此甜美與珍貴，恨不得自己能多尿一點。」 - 低求生機率
考量體力問題，分組獲救機率比較大。先是4人一組，因洋流關係再變成2人一組，最後由體力最好的教練，脫隊上岸求救，使所有潛水客獲救。
SW Tester的自救措施
針對前面提到的「SW Tester 的常見遭遇」，我的解決方案重點只有兩項：
- 停止抱怨
- 建立知識
第一步：停止抱怨
「存在就是合理，合理的才會存在」是我每次看到每個不合理狀況的解釋，這自然包括了客戶這間外資企業。
完美的公司並不存存，現實狀況下，員工會離開的原因往往是「錢沒給到位；心委屈了」，除此之外，管理制度不佳、欠缺員工教育訓練的機會，也常是職場上會遇到的問題。
以一個員工的角度來看，必須先能認同「有問題存在的必要性」。你想想看，如果這個組織沒有問題，自然不會有人要離開，也才輪得到你來坐這個位置呀！
一直抱怨問題，是不能解決事情的。只有停止抱怨、接受現況有問題，才能讓自己認清現況，並提出自己的改善之道。
解決 SW Tester 的心理問題，往往是最難的一點！如果不先解決這點，就等著被解決了。
第二步：建立知識分享的小組織
想要「知識分享」，就必須有分享的對象和被分享的來源，所以建立知識分享的小組織就是必要的第一步！
只是你必須慎選成員：不抱怨、認同現況、願意分享個人看法、並願意從自己做起的夥伴。
SW Tester 遇到的狀況，雖然沒有像案例內潛客的危機四伏，但也沒有好很多。如果 SW Tester 不開始自力救濟，就不會有好的表現；沒有好的表現，就不會有更好的報酬；沒有更好的報酬，並不會讓你想長久的待在一間公司；在一間公司待不長，並不會學到更多的東西；沒有學會更多的東西，是不大可能在同一領域就長久立足。但更有可能的是在一開始，沒有好的表現而被迫離開了這間公司。
簡單地說，SW Tester 遇到的狀況更像是「飢餓遊戲」電影內搶武器的圈圈，每個人都必須先找到可信賴的伙伴、搶到自己善長的武器和資源後，先離開這個危險的地方，然後找尋可生存下去的機會。
但在現實情況中，想要改變的 SW Tester 不是面臨找不到伙伴困境，就是遇到的伙伴不適合自己。因為並非所有的 SW Tester 都認同這個情況，然後意識到必須與其他人合作比較容易生存下去；也不是所有的 SW Tester 在認同這個狀況後，意識到必須與其他人合作後，就真的能與其他人分享寶貴的生存資源。
正是這些限制，讓 SW Tester 在現實環境中很難建立分享小組。
不過，不用擔心，即使只有 SW Tester 一人，以下的活動還是能夠繼續展開。
第三步：釐清/建立文件化的知識
人的問題不論是否能解決，都必須釐清有那一些知識對了解產品或執行測試有幫助、值得花時間蒐集。請記得，時間對 SW Tester 是很寶貴的！因為現實狀況下，主管給予 SW Teseter 的時間是極其有限的，SW Tester 必須掌握時間就上戰場發揮戰力，因為「即戰力」也是 SW Tester 的專業之一。
我給客戶員工舉的例子，是我針對目前專案所做的一本生存手冊，其中包含了一些重覆使用的命令、或不常用到的重要內容、又或者是從既有的 bug 或 test case 內學習到操作。有了這本手冊，讓我能一直在工作中參考，不用花時間到處翻找資料。
我在另一間公司的情況，是直接買實用的工具書，然後摘錄書中相關的資訊，以求馬上能應用於工作中。
第四步：建立知識分享的流程
這點其實是最重要的一點，透過知識分享，能極大化每個人的成果。
實際的操作，只要有新到職的同事我就會分享這份文件給他們，讓他們有機會去認識產品、並知道如何測試產品。同時，藉由分享這些文件，也可以透過善意建立自己的影響力。
你可以選擇放在公司內的某個 WIKI，也可以放在 Word 檔或 PPT 檔後存在網路資料匣中分享給其他人。不論放在那裏，切記重點是要放在能方便取用的地方，才能隨手取得，隨時觀看，隨時更新。
等等，你可能會問我「Jose 你不是說是 SW Tester 一人的活動嗎？那為什麼還要繼續分享？」
請記得，分享是一種開放的友善行為，表示你願意歡迎其他人隨時加入享用資源。也許別人一開始不願意加入，但因為你隨時都準備好分享了，只要你一遇到適當的機會，就能立刻展現你之前準備知識的價值。
當你找到伙伴後，我會建議同仁可以每周聚會一次，然後每個出席者都花點時間分享當周的收獲，然後有組織地將這些知識文件化，接著就能在下周使用到這些新的資訊。
只要重覆這些對的流程，參與的人在一段時間後，就能體驗到這些知識帶來的收獲，進而增加了 SW Tester 的生存機會。
第五步：改進知識分享的流程
如果你發現目前累積的知識，不敷使用或是內容不足時，就可應用 PDCA 的概念，不斷修正目前的流程。
可以改善第二步、讓更多能提供知識的人進入這個小團體；或是改善第三步、重新聚焦應加入的知識；或是改善第四步、修正目前知識分享的流程。
重點是你願意發現現況的不足，才可能提出可具體改善的措施。
小結
以上內容是我從「SW Tester」的角度，提出個人能力所及的範圍內所提出的改善之道。
當然，最有效的方式是從組織的政策、資源、流程去「改進」測試部門的不足。但倘若測試部門就是欠缺這些重要的流程/活動、單位主管也不知道/不願意做這些活動時，就可以從發揮個人影響力的角度，來「改善」組織的不足。
雖然「改善」的效果雖然比不上「改進」，但卻足以拉開與其他人的距離了。
我和大家分享一個故事：一架飛機在非洲失事，只有一個日本人和美國人存活下來、但是身上的衣服都破了，鞋子也掉了。這時來了一隻獅子要吃他們。美國人拔腿就跑，但日本人卻蹲下來把鞋子穿好。美國人問日本人為什麼不趕快跑？
日本人說，「等我把鞋子穿好後，不用跑得比獅子快，只要跑得比你快就好了。」
後記1
在本文中，因為使用「知識分享」一詞，所以後面都以「知識」來稱呼這些應被稱作「資訊」的東西。
後記2
我前面說自己會和同事分享這份文件，因為我不是這個部門的頭，所以他們是否真的認真去看裏面的內容，老實說我一點也不在乎。
不過，倘若這些員工是我的手下，我可就不會這麼輕易地放過他們。
首先我會直接告訴他們「知識分享」是我這個單位內很重要的一件事，也是年度考績的一個重要指標，而且會是逐月考核的重要項目。
另外，每個成員在進入這個部門無償獲得別人分享的心得時，就有義務分享自己工作的心得。
- 自由時報-《海漂百里 8潛水客全獲救》
沒有留言:
張貼留言