2017/09/27

How a SW Tester Self-help 軟體測試員該怎麼自救?

這篇文章原文是「Tester該怎麼自救?」全部都是以我以軟體測試員的角色親身經歷多間公司的不同狀況後,所提出試行有效的多種策略,希望能提供新進的軟體測試員參考。
scuba diving self-help
想像一下自己是個浮潛愛好者。

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

一潛下去先發現海面水流和海底水流相反,當你發現不對勁想上升減壓時,卻遭遇強勁的北上洋流。

你想往岸邊游,卻發現自己被夾在詭譎多變的沿岸流與黑潮強勁洋流間,只能隨波逐流。

這個時候,你會怎麼做呢?


SW Tester 的常見遭遇


對一般人而言或許不大可能遇到這種狀況,但對 SW Tester 來說,類似的狀況卻屢見不鮮。

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

組織僅提供了少數/有限的資訊:
  • 有User Guide,但裏面的內容不完整,也不足以幫助測試團隊了解產品。
  • 有Test Case,但步驟不清楚,有些步驟甚至只有一句話帶過,並沒有提供細部的測試資訊。
  • SW Tester到職後沒有訓練的過程,也沒有訓練教材。
團隊的部份:
  • 欠缺知識庫,所以,組織並沒有辦法提供 SW Tester 所需的產品相關資訊。
  • 欠缺知識分享/管理的流程,所以 SW Tester 只能靠自己從實際的測試活動中,累積和產品相關的經驗與資訊。
綜合以上的情況後,就變成 SW Tester 到職後才發現自己是前面說的浮上水面的浮潛客,得要自己面對一連串現實的生存問題:
  • 不知道該如何了解產品
  • 不知道該如何上手測試工作
  • 不知道該如何測試產品

浮潛客的自救措施


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

SW Tester的自救措施


針對前面提到的「SW Tester 的常見遭遇」,我的解決方案重點只有兩項:
  • 停止抱怨
  • 建立知識
當然,如果讀著有其他更好的解決方案,也歡迎大家分享。

第一步:停止抱怨


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

完美的公司並不存存,現實狀況下,員工會離開的原因往往是「錢沒給到位;心委屈了」,除此之外,管理制度不佳、欠缺員工教育訓練的機會,也常是職場上會遇到的問題。

以一個員工的角度來看,必須先能認同「有問題存在的必要性」。你想想看,如果這個組織沒有問題,自然不會有人要離開,也才輪得到你來坐這個位置呀!

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

解決 SW Tester 的心理問題,往往是最難的一點!如果不先解決這點,就等著被解決了。

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


想要「知識分享」,就必須有分享的對象和被分享的來源,所以建立知識分享的小組織就是必要的第一步!

只是你必須慎選成員:不抱怨、認同現況、願意分享個人看法、並願意從自己做起的夥伴。

SW Tester 遇到的狀況,雖然沒有像案例內潛客的危機四伏,但也沒有好很多。如果 SW Tester 不開始自力救濟,就不會有好的表現;沒有好的表現,就不會有更好的報酬;沒有更好的報酬,並不會讓你想長久的待在一間公司;在一間公司待不長,並不會學到更多的東西;沒有學會更多的東西,是不大可能在同一領域就長久立足。但更有可能的是在一開始,沒有好的表現而被迫離開了這間公司。
Hunger Game
簡單地說,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 的概念,不斷修正目前的流程。
PDCA Circle
可以改善第二步、讓更多能提供知識的人進入這個小團體;或是改善第三步、重新聚焦應加入的知識;或是改善第四步、修正目前知識分享的流程。

重點是你願意發現現況的不足,才可能提出可具體改善的措施。

小結


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

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

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

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

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

後記1


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

後記2


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

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

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

另外,每個成員在進入這個部門無償獲得別人分享的心得時,就有義務分享自己工作的心得。

沒有留言:

張貼留言