今天幾個測試圈子的大佬約了飯局，席間彼此交流了很多關於職場工作上測試相關的話題。
聽了他們的一些觀點很有啟發，我自己對於聊的話題也做了一些描述和實際的案例說明。
聊的第乙個話題就是測試leader如何保障團隊的質量交付，這個話題最近在很多地方，聽很多人聊過。我會嘗試從以下幾點來做闡述說明，觀點僅代表個人看法。
問：流程是什麼？為什麼要有流程？流程能解決什麼問題？流程能帶來什麼保障？
流程是什麼？
流程是保障團隊目標達成的最佳實踐，因人/團隊/業務型別/迭代速度/資源緊張程度而異。
為什麼要有流程？
沒有流程會導致團隊中的個體各自為戰，目標不統一，進度不協調，資源配給失衡而導致交付質量下降。
流程能解決什麼問題？
流程能保障團隊或者群體在大方向上保持協調一致，盡可能降低由於團隊人員能力、認知水平、資源不足、意外情況導致的專案延期或者質量下降。
流程能帶來什麼保障？
關於這個topic，我想用比較通俗易懂簡單直白的話來表述，想象乙個場景：
如果沒有流程，產品三天兩頭改需求，接還是不接？不接的話，產品投訴說需求很緊急，不做會影響運營指標、gmv、dau......等等很多理由，技術不配合，怎麼辦？
雖然說職場是個講規則講道理的地方，但實際上從業務和產品團隊的實際操作來看，當她需要和你講道理時候，道理才成立。如果她不想講道理，技術絕大多數時候就是故障定責時候背鍋的。
這個時候，流程的作用是什麼？流程可以保障你可以有底氣的據理力爭，雖然不一定能扭轉局勢，但在一定層面上，會哭的孩子有奶吃，偶爾學會受委屈給領導看，也是以退為進保障自己利益不受太多損失的技巧。
如何高大上的理解流程？
風險可識別+問題可追蹤+結果可驗證+資料可量化（記筆記，抄下來）！
聊完流程管理，接著聊聊需求評審。這裡不講大道理，只談實際操作的經驗。
席間，我開玩笑的說，需求評審是技術面對業務和產品時，最後一次的求生機會和保命措施。
職場是很現實的世界，每個角色或者團隊的kpi衡量維度是不同的。
運營看拉新效率、dau及履約轉化；
產品看出了多少需求，上了多少功能；
開發看的是完成了多少需求，線上穩定性；
測試看的是線上故障率以及故障的影響程度；
你看，都是職場苦命人，對老闆來說，大家都是被push的。
不同的kpi導致了一些新名詞的出現，比如：線上業務穩定性和線上系統穩定性，這又是另乙個話題了。
對技術團隊來說，先保證需求交付，在保障交付質量，其次才是和業務及產品的關係。關係不一定有用，但某些時候可以降低你的利益損失。
前幾天**了某個大佬的一篇文章：《測試如何提高自己的話語權
》，席間也聊到了這個話題。
知乎有個慣例是：先問是不是，再問為什麼。
測試在技術團隊中有話語權麼？
有，但大多數的測試是開發的附庸；
為什麼有一些測試會問這個問題？
在職場中沒有安全感，生存的危機感逼迫；
怎樣提高測試在團隊中的話語權？
席間我們聊這個話題時候，還是蠻有意思的。
有個大佬說他們公司有個技術大佬，cicd、自動化、效能測試玩的一溜一溜的，結果年底了業務投訴較多，績效只有b。
但另乙個人技術並不是特別厲害，但能hold的住業務和產品，能保證按時交付，業務和產品也沒有投訴，績效相對更好。
問題出在**？
做技術的往往陷入技術陷阱，特別是一些技術大佬，因為他們覺得問題超級簡單，為什麼產品和業務就不能理解呢？
很容易陷入對技術的推崇而忘記了產品和業務本身就不是這個領域的，技術和業務之間的壁壘還是很嚴重的。如果能通俗易懂的讓外行人也能聽懂你在做的事情對他們帶來的價值，才能更好的拿到結果。
這裡實際上就是自己懂和讓別人也懂的區別，說白了就是溝通和表達的問題。
而且在職場中，特別是上了規模的企業，溝通和表達有些時候，比技術更重要。有些特別明顯的例子：
如何提高自己的溝通和表達能力？
有時候我們容易陷入思維誤區，在職場中公事公辦，按流程辦事。邏輯上來說這樣是沒錯，但職場我們打交道的是具體的人，而不是問題。人有自己的情緒和利益考量，很多時候是屁股決定腦袋。
這裡大家可以看我之前的文章：《被忽視的問題：測試環境穩定性治理
》。裡面講到了我在牽頭做這個專案時，和dba以及基礎架構的同學是如何溝通的。下面是部分內容節選：
變更許可權收口我：xx大佬，我要搞測試環境穩定性治理，希望減少隨意的表結構變更和讓底層資料保持一致，需要你的幫助；
dba負責人：那可真是太好了，我一直想幹這個事情，但我去推業務那邊一直不搭理我，阻力很大。。。
我：那你看我們合作怎麼樣，我去和業務研發以及測試協調這個事情，你把底層的技術規範搞定？
dba負責人：沒問題，許可權收口，表結構變更統一走工單，降低變更頻次，規範資料庫和sql規範，我來搞定；
我：那行，你先準備相關的技術方案和規範，我們先挑乙個環境試點，業務方我去溝通，好了我們就開始搞；
dba負責人：可以，有啥需要我幫忙的儘管說，做這個事情對我們dba也是個好事情。。。
分享這個對話過程，實際上要表達的是：很多時候我們工作中面臨的痛點，也是其他人想解決的問題，尋求利益共同體，協作達成一件事，比孤軍奮戰更輕鬆，達成的效果也會更好。
測試環境容器化
基礎架構一直想推業務線接入容器，但一直很難推下去，理由也很正當：「業務迭代需求太多，沒時間沒資源接，而且穩定性也是要考慮的」。
正好我在牽頭做測試環境治理，希望能快速拉起環境和服務（ecs虛擬機器部署服務太麻煩了，速度還慢），結果聊著聊著，一拍即合。我負責和業務方溝通，基礎架構提供技術解決方案。
這裡要補充說明下，不是我有多高的職位和權利，才能去和業務方溝通。而是測試環境的痛點已經影響到整個技術團隊的需求迭代研發交付了，大家即使不太樂意，但這個問題不解決大家都很痛。
舉上面的例子，我要表達的觀點是：
以我個人21年面試的經歷來看，現在的求職市場，已經不僅僅只考察個人的專案經驗和技術能力了，而是更關注你做的專案落地的經驗。如何理解這句話？
很多同學簡歷會寫自己的擅長技能以及專案經驗，常規的面試流程基本都是聊技術細節，舉個我面試其他候選人的例子：
我：簡歷裡你寫了比較擅長自動化測試，聊聊你是如何做自動化的？候選人：我用的python+pytest+jenkins+allure框架，用了po模式，資料用excel維護；
我：為什麼會選擇這個框架，和其他框架相對比，這個框架有什麼優勢，能解決什麼問題？
到這裡70%的候選人基本就卡殼了。。。
當然，上面的描述只是乙個例子，我一般還會問其他關於自動化的問題，比如：
我實際上並沒有直接問純技術的細節，而是在試圖引導候選人，對自己做這個專案的一些想法，包括技術框架選型，擴充套件性如何考慮，如何對結果進行度量等，希望能聽到更多實際的思考和遇到問題如何解決的。
上面談了一些很有意思的點，我盡量用通俗易懂的話表達出來。這些也是我自己工作中曾經遇到的一些問題，希望看到這篇文章的同學，能對你當下面臨的問題有所幫助。
測試工程師簡介
一 什麼是軟體測試？1975年，兩位軟體測試先驅john good enough和susan cerhart 在ieee上發表了 軟體資料選擇的原理 此時將軟體測試定義為 證明軟體的工作是正確 的活動。1979年，glenford j.myers的著名的 軟體測試藝術 對測試的定義是 發現錯誤而執行...
軟體測試工程師
首先，最根本的還是要看企業自身的需要，綜合自己的測試團隊力量，自己公司的研發狀況，當然還有公司的資金 到底到測試這塊公司願意投入多少money呢?另外要搞清楚自己公司招聘測試人員的目的是什麼?比如，如果公司暫時還沒有測試團隊，這個時候公司剛好有財力，同時研發力量比較大的時候，因為發展的需要，必須要組...
寫給測試工程師
你要為自己每一次的懦弱而懺悔 曾經不願承認自己出生於農村，曾經不敢面對自己是一名外包員工，曾經一次次的不甘心自己只是一名測試工程師。不做失敗者 微軟 ibm oracle 華為等等，這些公司選拔的測試工程師應該都是出類拔萃的人才。可惜不是你，說起你的大學，就想起郭敬明的 一夢三四年 你開始想做測試是...