前言
大多還未踏入或者剛剛踏入測試這一行的小夥伴都會經歷一個迷茫期，那就是測試到底是幹什麼的。甚至有些步入測試已久的老鳥們也會時時的質疑自己正在做的事情。覺得自己就是在找茬，打雜甚至覺得自己做的事沒什麼意義。所以我們今天就來嘮叨嘮叨吧。我有幸經歷了我們公司最重要的專案誕生的過程，並一直堅持到了現在。所以我以我的經歷為背景跟大家探討一下QA這個行業。當然我也有很多做的不好的地方，大家可以當做借鑑。這裡我就不說什麼測試用例設計什麼的這些初級階段了，我們們直接上核心的。
QA能力之一：以質量和效率為中心，發散式工作
在很多公司，很多小夥伴都會迷惑一個QA應該幹什麼，有些事你覺得是打雜，有些事你覺得技術含量太高應該開發和運維做。那麼QA到底該幹什麼？ 一句話總結出來就是凡是能提升質量和效率的工作，你都可以做。當然很多事情不一定要你親力親為，但你要有能力組織這件事情，找到合適的人去做細節。你要成為那個牽頭的人，跟蹤進度的人，掌控風險的人，協同各部門一起完成目標的人。說白了，你牛逼你就自己搞定。你不牛逼就組織大家一起搞定。 這其中的溝通能力和在專案中的影響力大家應該明白。我有個習慣，就是每做一件事之前都問問自己做了這件事能提高生產力麼？ 如果是能，那就做。不能，那就一邊去，等小爺閒的蛋疼的時候再說。我建議大家也這樣，免得做了很多無用功。
舉個例子，之前專案剛開始沒多久的時候所有開發人員的配置都是散落在很多不同的檔案裡，每個模組的配置檔案也都散落在不同的位置。 加之系統很複雜所以部署一個環境極其困難，當初我是廢了九牛二虎之力才把專案中所有的關鍵配置梳理清楚，寫出了自動化部署方案，這是提升效率的一個點，我能力尚可自己搞定了。但這也就造成了當時只有我能單獨搭建起一套環境的窘境。我連個假都不敢請，因為公司所有的開發環境，測試環境的命脈都掌握在我一個人手裡。而且這以後上線的時候，進場部署的時候得多痛苦。所以一個配置管理方案的誕生迫在眉睫，這個事情我就麻爪了。小爺我就是個二手的開發和運維，這方面菜的很沒啥經驗，讓我自己設計一個好的配置管理架構基本是扯淡。所幸開發人員中有人做過專業運維，以前搭建過ZK做配置管理。所以我直接叫上他和所有模組負責人一起討論一個配置管理方案。他寫config server，另一個人寫config client其他模組負責人做整體遷移配置。 最後我來一個部署測試。計劃基本就是這樣，然後大家就各自行動。我統一排期，跟蹤進度，提前把問題暴露出來等等工作。可以看到在這裡我除了最後測試一下沒幹什麼具體的事情。事情都是大家做的，我只是牽頭和打雜的。就像之前說的，自動化部署這事我牛逼，所以我做。配置管理這事我不牛逼，所以我求著別人做。
QA能力之二：影響力
影響力是QA的命脈。QA在團隊中一定要有足夠的影響力，這樣你在推行任何策略和流程的時候人家才不會把你當成個屁不理你。簡單來說就是你得能讓人家服你，讓人家覺得你推行的東西是靠譜的。就像上面組織配置管理方案一樣，我要是之前沒積累出點影響力，你當他們會理我麼。那怎麼提升QA的影響力呢？我的經驗是解決其他人最痛的痛點，他們會感謝你，會覺得你是有水平的。會覺得你跟他們理解的只會隨便點點的QA是有本質區別的。
舉個列子，一般開發和產品最痛的痛點是什麼呢？ 答案是環境，越是複雜的系統，環境越是讓開發和產品人員痛苦的欲罷不能。就拿我們這來說吧，系統比較複雜。而且是多語言開發的。什麼NODE.JS，java，python，scala，c++。還得有一套hadoop2.0叢集跑任務。搭建一套環境的成本之高令人髮指。當時開發，測試，產品都用同一套環境。是各模組的開發人員臨時糊出來的，每個模組的開發人員各自搭建自己的模組，然後拼成了這樣的環境。大家都用一個環境的痛點就是互相影響，踩踏。這邊QA正測呢，開發重啟server了。 那邊前端的開發人員正除錯呢，後端又要重啟server了。 產品人員內部演示呢，這邊一個模組的開發又說要重啟server了。所以當時每次開會的時候大家都在抱怨環境的互相踩踏最影響效率了，開發人員希望有自己的環境不被他人影響，產品希望有穩定的環境隨時演示，QA也希望自己的測試環境不會被開發隨意重啟改動。 所以那時候我就把自動化部署這個任務承接起來了。 開始引入docker，跟每個模組的開發確認部署細節，約定部署路徑，還要溝通分配專門的網段，伺服器等等。然後就在某一天，10幾套環境就在server上拔地而起。每個開發和測試都人手一套環境，部署簡單，並且每個環境都保留了git目錄，定製了拉程式碼和重啟服務的指令碼，自動開啟ssh，mysql client等等等等。開發可以隨時在自己的環境裡編輯原始檔，直接在環境上開發。自此開發很happy了，QA在測試的時候也不會有開發人員跑來重啟環境，QA也很happy。 我們還專門給產品人員搞了一個穩定環境，這個環境裡功能永遠是可用的。所以產品也很happy。直到現在已經在docker伺服器上啟動了20多套環境，開發人員反映生產力翻倍，閒聊開玩笑的時候說誰離職了你也別離職啊，你走了環境怎麼辦啊。雖然是開玩笑吧，這年頭缺了誰地球都照樣轉。但是聽到了以後我自己還是蠻開心的。
QA能力之三：掌控力
QA應該是最瞭解專案的人，不僅是業務上的，還有產品架構，當前迭代的進度，可能的風險和問題都要了然於心。當然有廣度就行了不一定要有多深。但是你一定能把握的住當前的節奏，在團隊過於發散的時候負責把他們拉回來，在團隊遇到問題和風險時及時告知甚至提前告知團隊的成員們，在團隊效率不高時引導他們。你不是專案的管理者，但你是專案的監控者。你要確保專案能如期按質保量的將產品帶上線。而且大多數的時候是要權衡利弊，互相妥協的。開發和產品和QA之間永遠在互相妥協。但如果等到快釋出的時候才讓大家知道問題，這時候再妥協已經來不及了。在你的列表裡一定要有這麼一份報告。它記錄了本輪迭代所有要提測的feature，feature的owner是誰。提測的deadline是哪天，開發過程中有問題麼，有沒有提測延期的風險，提測後遇到過什麼問題，測試的QA是誰，當前的測試進度怎麼樣。以及當前有多少bug，其中p1和p2的有多少，p3，4，5的bug有多少，當前的bug情況有可能危及到釋出麼。還有本輪迭代是否有非功能性的重構，優化，是否對效能有要求，如果有，效能測試的計劃和用例的也要跟蹤。還有相容性，部署等等。掌控住所有的資訊後你方可作出判斷，對當前的情況作出風險分析，列出優先順序。然後跟開發和產品一起討論，如果都能解決當然最好。不能全都解決的話，就要根據你列出的資料和優先順序，開始互相妥協了。需求該砍砍，bug也要妥協。嚴格定義bug的嚴重級別。高優的修完便可，低優的妥協掉，放到下個迭代再說。
再舉個例子，專案第一次釋出前兩個禮拜，我統計bug的時候發現bug過多，而當前仍然有很多feature沒有開發完，預計在釋出當週才能開發完。我判斷以當前未完成的feature和bug量對與釋出來說是一個嚴重的風險。於是找來產品和開發的leader，討論一下當前的優先順序，每個模組出一個人進小黑屋修bug，務必在下一輪測試前把bug量降下來。於是每個人好吃好喝供著，全都進了小黑屋修bug了。 還有一次在驗收測試之前的那一輪測試中。第一天QA就發現問題比較多，這樣很可能影響驗收的結果。而如果驗收不通過，就需要修bug重新驗收。而我們在時間上根本沒有給再跑一輪測試的buffer。所以這時候QA必須站出來發出聲音，把風險都提出來，於是又一堆人進了小黑屋了，沒開發完的feature也砍了。QA是那個總在質疑的人，我們天性使然。
我舉的例子不是說有風險就要砍需求，而是各方權衡，妥協的結果。如果釋出時間不可動搖，解決不了的必然就得砍。而如果需求是不可妥協的，那釋出時間就得延後。就像我上面說的，一切都是三方權衡，妥協的結果。
QA能力之四：改進力
QA以提升產品質量為天職。找出產品的bug是直接的提升方式，這裡面就有測試計劃，測試用例的設計等等，這裡我們不詳說了。 但我們有一些間接的方式，一般分為兩種。第一是提高生產力，就像上面的部署自動化。節省了工程師的時間成本，就是間接的提升產品質量。一般提搞生產力都是通過工程自動化，或者開發一些工具來提升效率。像我們搞得CI，自動化測試什麼的都是這一套。第二種是過程改進，通過改進當前迭代的各種流程，規範標準以減少我們不必要的人員浪費。
改進力的例子就太多了，就像剛才說的我們做的各種自動化其實就是一種改進。而在創業團隊中，過程改進更為常見。一開始大家都是個人戰，小團隊中大家憑藉優秀的個人能力就能hold住所有事情。但團隊越來越大，產品越來越大，已經不是每個人都那麼優秀了，而且即使大家都很優秀但一個人一個工作習慣。個體的不同已經給團隊帶來了很大的麻煩。這時候大家要開始互相妥協，統一一個相同的步調。這就是無規矩不成方圓。開發產品QA要經常總結，對各種流程達成一致，並全力推行下去。每個團隊的情況不一樣我就不舉例子了。
QA能力之五：應變力
軟體行業有一句很有名的話，叫做唯一不變的事就是需求永遠在變。尤其是風口浪尖的網際網路行業，變化是家常便飯。 敏捷開發模型的口號也是擁抱變化。記得我之前在測試開發之路--噴噴埋雷的事，吵吵程式碼的情中講過在自動化測試中的應變，這依賴良好的設計和豐富的經驗。有興趣的看看之前的帖子吧。 除了在自動化中的應變，其實我們還有別的。 例如萬一有個人離職了怎麼辦， 某件事情的key person請假了怎麼辦。提測延期，測試時間不夠怎麼辦，伺服器down掉，短時間內無法恢復怎麼辦。這些都要提前想到，免得到時候手忙腳輪的。QA是質疑一切懷疑一切的人。千萬別以為事情會按部就班的照你的意思進行下去，據我的經驗，幾乎沒有一個專案是那麼順利的。起碼排期的時候你要留buffer，專案開展的時候前緊後鬆，人員上互為back up，如果依賴叢集記住一定要留個單機版的叢集以防萬一，掌控專案的所有資訊，獲得第一手資訊並立刻思考解決方案。好了這點就說到這吧，這些都是經驗上的東西了。我也還欠缺很多，也是時常有手忙腳亂的時候。
QA能力之六：執行力
這個更不用說了，你再敏捷開發團隊中，執行力是根本。一個字，快。沒有那麼長時間讓你慢慢思考設計了，隨著工作經驗的增長你要總結出一套可用的方法論，框架，工具。關注你使用語言的各種開源專案很重要。我之前的帖子寫過，能用開源的就用開源的，千萬別裝逼自己寫。等你寫出來，黃花菜都涼了。我為什麼喜歡用docker？ 因為快，搭什麼服務下個官方映象我就用，搭個mysql撐死5分鐘（還是網慢的情況）。只要你對這些東西不陌生，像test link，Jenkins，jira，wiki等等這一套基礎服務從無到有撐死也就一下午的事。拋棄你那顆想研究細節，想研究原理的心，等你空餘時間再研究吧，記住專案質量優先，它永遠都是最重要的。
QA能力之七：技術能力
終於說到這個了。我就不發散的說別的了。。。又要囉嗦一大堆了。 技術能力。。。是以上六點的基礎，沒有技術能力以上六點均為扯淡。可以看到我把技術能力列為最後一項了，因為確實當你負責一個專案的質量的時候你需要用到的技術能力越來越少，因為你需要關注的東西更多，更廣。很多細節的事情，例如寫自動化指令碼，寫測試框架可能已經交給你的同事來做了。但你千萬別以為你可以不用擁有技術能力，當一個純的manager。那是扯淡，扯淡中的扯淡。舉個例子你啥時候聽說過CTO可以不懂程式碼的了？雖然他已經不用再苦逼的當碼農了但是沒有高超的技術能力他怎麼帶領技術部？同理如果你技術為0，完全的外行領導內行。你怎麼理解產品架構，怎麼制定測試策略，你怎麼把技術能力轉變成生產力，同事在走上歧路的時候你怎麼及時發現並更正。退一萬步講，你沒技術能力怎麼服眾，怎麼防止其他人糊弄你。反正如果我領導完全是個技術白痴的話我糊弄他跟糊弄孫子一樣。
最後說一句，一定的技術實力是基礎。。。真真的是基礎。。。不要把懂技術當做很高大尚的事情。也就測試圈子覺得會寫程式碼會搭架構就是大牛了，要知道軟體這行裡高手到處都是，你測試圈子裡的技術人家根本不看在眼裡。
結尾
好吧我又囉嗦了一堆，以上均為我個人見解，不代表廣大群眾。有錯的有對的都請輕噴。