老實講,這個標題由一個RD了大半輩子的程式設計師來下,怎麼看都滿奇怪的。不過,如果是「身為一個跟著team並肩作戰個十幾年」的RD來講的話,「未來團隊會需要怎樣的QA夥伴」這觀點,也許能幫助到一些目前不知道未來要怎麼走,以及不知道目前要不要入QA(其實是QC)這個坑的朋友參考。

其實嚴格講起來,在軟體產業絕大多數的QA其實是QC。關於QA跟QC的分別,可以參考一下這篇文章。不過,由於長期廣泛的誤用,所以大多數用語上都是直接用QA來替代。不過,真正的QA其實是一條截然不同的道路,而且這條道路通常也有一大半的人是從RD或者PM走過來的。簡單的說他們的差別大概就像:

  • 我們普通測試app,不管用手動還是自動,這些都是針對「產品」,都是屬於QC的範疇。
  • 大家有時候會很頭大的ISO Audit(如ISO 9001),這些都是針對「產品流程」,這些才是屬於QA的範疇。

先有這個認知,我們這篇主要是著墨於QC這個職業的Career Path(職涯規劃),而常常被誤認的QA則是另外一條截然不同的道路,不會在這篇裡面提到太多。

許多人對QC的認知

很多人認為,QC就是RD在Unit Test的下一站,通常來講就是專門做「動手玩」這塊。以app來講,就是操作app,找出corner case,找出跟規格(spec)不同的地方,開issue來回報給RD或者PM —— 假設這個行為沒有被清楚定義在Spec裡面的話。說實話,這塊門檻是真的不高,所需要的主要是在產品合作累積的Domain Knowledge(產品知識),能夠隨著經驗增長,較快地對新的版本測試「較可能出錯的地方」。然而,這些知識都是屬於「帶不走」的,也就是當你想要尋求更好的機會的時候,很遺憾,這些都是屬於「換個產品這些知識通通都得打掉重來」的,你能在這個工作得到的經驗無法順利轉換成下一個工作的優勢。

並不是說這個不好,這個其實是QC的基本;但是如果只有這塊的話,其實對於職涯發展是非常不利的。

進階一點則是做Test Report,能夠敏銳的察覺這個產品需要設計什麼測試流程,整個測試邊界要怎麼設計,能夠經由一些詢問以及判讀來快速擬出一個測試計畫 —— 比方說今天團隊更改了A模組,你可以很清楚知道B也需要重測,重測範圍大概是哪些等等。即使沒辦法很快判斷,也可以藉由跟RD/PM溝通快速的勾勒出,在這次Release以前需要測試哪些地方。這些經驗相比於前面,是屬於「帶得走」的知識,也就是可以快速都轉換成你下一個機會的籌碼以及優勢。

為什麼或多或少要學一些Code

然而,這些傳統的QC技能,被目前蓬勃發展的CICD給衝擊到了。CICD不是本篇的重點,所以我只把他概括濃縮到幾個字:「每一個commit都要被測試,所以我們可以發現是哪個commit搞砸了」。所以可以猜到,這個測試量將會非常的高,高到沒有任何一個手動的QC團隊能夠接下如此大的工作量:我舉個例子,我某個團隊一天會有超過80個commit,而要QC去測這些東西是不現實的。所以,大多數團隊的折衷方案就是,RD去想辦法把這些測試自動化,只有最終release會需要QC團隊的介入。

其實RD team對這方面並不是專家,他們能做的多半都是Unit Test的範疇,也就是說他們的測試僅僅止於該模組。但是對於CI來講,僅跑Unit Test可能會略有不足,所以定期(每天)或者每次commit仍然會需要Integration Test,甚至E2E Test:也就是以往QC夥伴們做的事情。所以RD就得自己去寫code想辦法把以前QC做的事情模擬出來,比方說如果這個product是API,就得使用比方說Robot Framework去跑一次整個Restful APIs;如果這組code是web page,就得想辦法利用如Selenium之類的東西來跑一次UI測試。當然,視覺上的問題自動測試的確無能為力,但是越來越多的測試都在被漸漸的自動化!而這些本來都是QC的機會。

事實上,RD對於做這些事情並不擅長:他們不清楚Test Scope的概念,很多corner case也不會抓,更不用講寫出來的test case一團亂。所以團隊會慢慢的變成,由RD提供Framework給QC,在由QC團隊來寫Test Case。不過,隨著QC這職位慢慢進化,熟悉自動化框架(如上面提到的Robot Framework跟Selenium以及更多)變成了一個QC本身極大的加分點。即使不熟框架,但是語言上的需求(如Selenium跟Cucumber都對於Java有相當的需求)要是能滿足的話,這個加分將會非常的大。

QC進化論

打開一些Job Finder,我們可以常常看到一個名詞:Automation QA(或者QA Automatic),甚至有一些公司直接把QA/QE Engineer定義為這個(我個人覺的這也是典型的QA/QC誤用,不過算了 XD)。手動QC其實會慢慢式微,而對於自動化的需求會越來越高。

有時候我常常會聽到一個誤區:QC技術門檻跟薪水範圍都低於RD。平均起來的確是,但是一個嫻熟語言以及框架的Automation,其實他技能上就是個RD —— 只是他偏好寫測試code,甚至他可以經由閱讀一些大方向且寫作良好的程式碼,能夠輕易發揮出普通RD做不到的Test Planning,Test Scope Definition等等。以職涯發展來講,這種QC絕無可能薪水低下,也不可能會有太高的可取代性。由於目前QC夥伴仍有許多沒機會發展這些技能,以至於讓這個職業「看起來」門檻低,「看起來」薪水不高。然而,這職業隨著進化,已經不是這樣了!更重要的是:技能門檻低的QC,可取代性太高,未來轉換跑道的籌碼會越來越少。

我能給QC職涯技能的建議

我個人認為技術能力方面,我推薦的框架跟語言

我推薦可以熟悉一下的壓力測試工具

這幾個其實算比較基本的,不過在整個日新月異的環境下,能熟悉一點這些技能,有助於快速pick-up以及應用在新的專案上。這些都是自己累積的資本。而且,如果有興趣入坑真正的QA去改善「產品流程」,這也將提供相當堅實的基礎。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。