通達人驛站: SQA的職涯規畫--回應讀者W先生

讀者W先生寫了一封信問我關於SQA的職涯規畫。

因為讀者敘述的問題，其實普遍發生在台灣的軟體公司內，所以在徵求讀者的同意後，以文章的方式回答。

不過，我得先向W先先說「對不起」。

因為在以下的文章中，除了引用自己的文章外，並沒有提任何一個網站、書。因為我相信讀者在Google 的過程中，可能找到的資料會比我所列的更新、更多，所以我將分享的是自己實作後被驗證有效的方法。

他的來信

如下：
1. 我是當了QA才開始學軟體測試, 而我目前的工作環境是一個從無到有的測試單位, leader也非科班出身,我們始終是邊學邊做,但對於產品的quilty都是以越來越多的test case來強化自己的信心,卻沒得到對應的成效.

2. 我拜讀過您的Tester VS SQA的文章, 我也很認同您對Tester的看法,但我目前就是在這個位子,哪我能透過怎樣的訓練或是學習來朝著 SQA的方向邁進嗎?

首先

你說的這些情形我不但不陌生，而且還親身經歷過，我相信這是台灣中小型軟體公司普遍的情況：

從業的人員普遍不是軟體背景的人，像我自己就是工業管理背景，
也曾經在從無到有的測試單位，
我的leader多數非科班出身，
我的經驗也是從工作中邊學邊做開始，
我也曾經以為有越多的test case，就能強化自己的信心（或是客戶對我們的信心），但最後卻沒得到對應的成效--Bug還是持續層出不窮的以我們想不到的方式出現，完全沒有收斂的跡象。

我猜這時候的你，可能有點灰心了，正在想自己是不是少做了什麼？不然為什麼已經做了那麼多，但卻一點效果都沒有呢？

恭禧你

我這麼說，有兩個原因。

首先，有很多人在這個時候就不再繼續思考，轉而放棄繼續掙扎、或乾脆逃離這個職位，想直接避開這個問題。

但他們不知道的，這是台灣軟體測試業界、尤其是小型的公司普遍的現象，所以不管到那裏，他們都還是會重覆遇到這個現象，除了嚴重的程度不一、或多或少也有你說的情況。

其次，你很幸運，還有人可以問。我以前遇到這個情況時，根本找不到人問，只能自己從外國的網站和書中去找答案。

第一個答案

這個問題的根源就不是發生在你身上，你何必一直為難自己，想從自己身上下手？

我這麼說好了：如果有一個縱火犯到處放火，不管消防隊不管他們再努力的滅火，他們都不敢確定有能力把所有的火滅完，更何況現實中有很多個人在犯火？因為有個很不等稱的現象：放火只要一個小火柴就可以了，但滅火卻需要一群人和消防車。

所以，你以為消防隊遇到縱火犯時，是只被動的救火嗎？絕對不是！

他們把火場的鑑識報告交給刑警，由刑警從火場的情況去分析那些火場是有關聯性的，再由行為模式確認縱火犯是隨機性、還是計畫性犯案，犯案手法為何？在了解縱火犯的行為常模分析後，才有更多機會抓到縱火犯。當然現實的狀況中，刑警可能會自顧不暇，因為同時間還得抓經濟犯、詐騙犯...。

在軟體測試上也有同樣的現象。軟體測試的資源（時間、人力）遠比軟體開發的少，軟體開發的時程可以一直延長，所以軟體的Bug可能會一直產生，但軟體測試卻得如期完成。而且抓不到Bug，帳是算在軟體測試的頭上，而非產生Bug的團隊頭上。

在這種情況下，不論是誰都無法把事情完成！所以不要再嘗試為難自己了，因為這就是軟體測試的侷限性。

第二個答案

你的方向是正確的，不再作滅火的消防隊，轉而作刑事鑑定、嫌疑犯行為模式分析的刑警。

但要怎麼做呢？

首先，你一定得要有個支持你的主管。就像導入任何系統化工具（如：ISO、CMMI）的首要條件。

這個主管必須有軟體品質的概念、所以能完全了解我上面說的「軟體測試的侷限性」，也體悟到需要的不是越來越多的Test Case，而是改做分析Bug的工作。只有了解每個重要Bug後的Root Cause，才能藥到病除地把病源根治，而非頭病醫頭、腳痛醫腳。

另外，軟體開發部門的主管也得支持你。

我很幸運，我的某一個主管曾經就是軟體部門的頭頭，他俱有軟體開發正規化的相關經驗，所以能放手讓我嘗試。只要我的手法和他討論確認後，他就會支持我所提的方法。像《Defect Pattern實作》，就是被實作過、也被確認有效的手法之一。

我也是不幸的，因為至此再沒遇過這樣的主管。不過能遇到挺你的主管，是每個人的造化，也是每個在職場上打滾的人必須面對的現實。

所以，實施SQA的環境，取決於客觀的環境，而非主觀的意願。但加強自己的本職學能，卻是我們能做到的。因為你得先變成俱有SQA的思維的千里馬，才有機會在伯樂出現後大展身手。

以下，就是我建議的方法。不過，根據我的經驗，換個老闆，可能比換老闆的腦袋容易。

「見林」

是從建立「觀念」出發。

我是工業管理出身，但你可能不是，所以我建議你可以從《Tester v.s. SQA - 1/ 從品質觀念談起》一文出發，去自修看更多關於「品質」方面的書。

為什麼要了解品質呢？

因為軟體的品質觀念與手法，其實落後於品質觀念的演進。就像我們現在常見的CMMI ML5，大概也只有1960年代到1980年代的水準，但在軟體業卻已經很了不起了，更別說有些公司連ML 2都做不到了。

當你俱備了品質的概念後，就可以在心中建立一個「品質概念」演進過程與實施細節的「林」，爾後當你再看到一些軟體品質手法時，你就會知道這些手法是這個「林」裏的那些「樹」。尤其是你那時再回頭看CMMI和ISO，你更會有這樣的領悟。

「見樹」

是從「實作」著手。

其實我已經在《Tester vs. SQA - 3/ SQA》中，已經揭櫫SQA的執行七步驟了，你可以用關鍵字去Google外國的軟體品質手法，這些資料非常多，尤其是NASA。

在翻譯的過程中，因為你已經先具備了品質概念，你會一步步的思考別人說的軟體品質手法，和過去自己學到的那些觀念、理論相比有何異同，最後得出自己的理解。我也曾這麼作過，雖然很花時間，但很有效。

最後

有了觀念和手法後，再回頭看工作的現場，試著釐清最重要的問題，用一句話描述問題。因為只要能清楚描述的問題，才有機會提出可能的解決對策，然後嘗試每個對策，直到找出最有效的。

如果你覺得太麻煩？

那很好！因為你不一定適合SQA這個工作，那就趁現在重新思考自己的職涯規畫，找到真正適合自己的工作。

SQA這個工作需要的特質是：擅長邏輯思考、堅持正確的信念、自我學習、不怕溝通與對品質的熱誠，如果你沒有具備上述的特質，沒有預先建立正確的原則，你將不知道該在那些大事上堅持、該在那些小事上妥協，更容易迷失在工作中，尤其是在現實清況中我們得時時與現實困境掙扎、妥協。