2011/10/26

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


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

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

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

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

4 則留言:

  1. 現在一些比較新的開發方法論都不再特別強調文件, 測試人員若不能透過文件了解測試任務, 類似像是Exploratory Testing, Context-driven Testing都強調透過不斷的溝通與學習來了解並完善測試的工作

    回覆刪除
  2. Hi Swift Wang,
    你可以提供不文件化的情況下,如何「不斷的溝通與學習」以「完善測試的工作」?
    我實在想不出有什麼「不文件化」就能達到的方法。

    回覆刪除
  3. 比較有效簡單的方式, 面對面跟Stakeholder溝通, 包括客戶/使用者/BA/SA/PM...
    有文件當然是最好, 但是Tester往往面臨著文件不足或是不正確的嚴重問題, 只好尋求其他的替代方案來解決, 甚至還要幫忙補足文件, 或許這也漸漸變成SQA/Tester的價值...

    回覆刪除
  4. Hi Swift Wang,
    如果要SQA/Tester補足文件,我沒什麼意見。但前題是他們已經具備了相關的知識、與測試眼前產品的能力。
    如果他們的知識與能力連測試也無法做好時,遑論補足文件?這不是本末倒置?

    回覆刪除