Posted by 
老實講，這個標題由一個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職涯技能的建議
我個人認為技術能力方面，我推薦的框架跟語言
- Selenium (Java)
- Robot Framework (Python)
- Cucumber （Java）
我推薦可以熟悉一下的壓力測試工具
這幾個其實算比較基本的，不過在整個日新月異的環境下，能熟悉一點這些技能，有助於快速pick-up以及應用在新的專案上。這些都是自己累積的資本。而且，如果有興趣入坑真正的QA去改善「產品流程」，這也將提供相當堅實的基礎。