因為讀者敘述的問題,其實普遍發生在台灣的軟體公司內,所以在徵求讀者的同意後,以文章的方式回答。
不過,我得先向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這個工作需要的特質是:擅長邏輯思考、堅持正確的信念、自我學習、不怕溝通與對品質的熱誠,如果你沒有具備上述的特質,沒有預先建立正確的原則,你將不知道該在那些大事上堅持、該在那些小事上妥協,更容易迷失在工作中,尤其是在現實清況中我們得時時與現實困境掙扎、妥協。
附註
我本來想寫一些Tester的職涯,不過一來怕影響本文的前後連貫,二來也不是讀者的問題範圍,三來我對Tester的興趣不大,就先作罷了。
好文章耶,給你鼓鼓掌。^_^
回覆刪除希望你不久後退休時,也可以寫一篇:
「全職專業投資人的生涯規劃喔。」