運維

我當測試總監的那幾年

題圖: from Zoommy

最近一直在忙GTLC與GIAC兩個大會的事,所以公眾號更新晚了幾天,還請各位讀者擔待。

今天來跟大家聊下我當年做測試的一些經歷。

每次問我有關職業發展的問題時,我都會反問兩個問題。一是你當下最喜歡做的工作是什么,二是你當下最擅長做的工作是什么。

面對這兩個問題,大部分人的回答都很相似。先是一愣,然后含含糊糊的說三個字 “不知道…” 或  “沒想過…”。

的確,吃喝玩樂,娶妻生子,才是大多數人的基本訴求,什么理想與目標,似乎都不是你蹦一下就能夠得到的,這種感覺像極了一頭拉磨的驢子,只能蒙著眼睛不停的向前跑,否則就會挨鞭子。

我常說,哪有什么人生規劃,都是歷史機緣的巧合罷了。

就像我的簡歷,凡是看過的人都會問:“你做過測試?為什么會選擇去做測試呢?”

選擇?對和多人來說,職業生涯的發展真的是選出來的嗎?一切都是被迫的,一切都是莫名其妙的。

在 #我是技術男,也曾創業過,也拿過風投……# 的篇尾,我說自己帶著兩年的創業史,身背近五十萬的債務,來到了大智慧辦理入職手續,開始了新的人生。

這段臺詞非常耳熟,像極了小時候看到的童話小說,王子和公主從此過上了幸福快樂的生活,恩愛一生。

很可惜,人生畢竟不是小說,把一個人寫死了,還可以用某個場景讓他復活。

相信大部分的人都有過走投無路的經歷,在殘酷的現實面前,什么理想,什么目標,都變得毫無價值,能活下去,才是當務之急。

2011年底,那場創業悲劇,讓我和我的家人幾乎陷入了萬劫不復的地步。

在公司開始清盤的第二周,有位朋友給我介紹工作,說是大智慧在招聘架構師,對口研發中心的HRBP正好是他女朋友,問我有沒有興趣。

這真是天無絕人之路,來早不如來得巧,關系那么鐵,我自認為八九不離十。

“太感謝了,沒想到就我這點破事,你還掛在心上了。”

“先別忙著謝,有個事情要先說下,這個正在招聘的崗位歸屬測試團隊,也就是說,如果你過去,職位最多是測試架構師……”,電話那頭的聲音顯得有些無奈。

“不知道你是否在意?聽說這個崗位他們招了半年,一直不理想,我覺得你肯定能夠勝任。”

對當時的我來說,與崗位和職務相比,收入與穩定性對我的吸引力更大。

“無所謂,幫我安排面試吧,”,這種爽快程度,連我自己都不敢相信。

“你下午就過去吧,我女朋友那邊已經給你安排好了。”

以前的我從來都不信什么牛鬼蛇神,也不信小說上那種純情的完美結局,但此時此刻,我似乎感覺面對未來以后充滿了希望,但又無法面對。

面試進行了2個小時,面試官是當時的測試總監,近四十的年紀,說話很穩重。

在談話中,我們交流了有關阻抗測試的各種問題,并探討了一些傳統測試轉型的方法。

這方面的記憶力是我的強項,至今我任然記得一些:

1、只能發現問題,無法解決問題

測試環節,常常在代碼編寫之后,就算測試小伙伴的能力再強,通過九牛二虎之力測試了致命性問題,但為時已晚,要想重新折回頭處理其中的問題是要花費一些時間和精力的,降低了交付效率,如果不打回修復,則無法保證質量。

2、有能力的不愿意做測試

從事測試工作的小伙伴,一般都沒有研發能力,有研發能力的一般也不會來做測試,畢竟無論從地位,還是收入,開發都要比測試高一些。

這就形成了馬太效應,好的越好,差的越差。

3、業務測試與業務驗證,傻傻分不清

通常情況下,討論需求的時候,業務方都會叫上開發,畢竟需要開發去實現,但絕不會叫測試。

這里會形成一種尷尬,因為測試員不可能理解所有的代碼,而且沒有參加需求環節,所以漏掉一些重要的測試是很有可能的。但業務方不會遺漏,畢竟這是他們的工作核心。

因為,我們經常會碰到,測試沒測出的問題,卻在業務驗證時發現了。

然后有趣的場景出現了,業務怪開發,開發怪測試,測試直喊冤枉。

4、測試環境是世界級難題

測試環境,是每家公司最頭痛的問題。比如測試通過,生產報錯,再比如測試人員編寫的測試是依賴的文檔或其他東西,而不是代碼,配置和數據存在任何不一致的地方的時候,就會造成問題。

另外,如果測試不是自動進行的,那么極有可能不會被頻繁、經常性地進行,這大大降低了發現環境問題的可能性。

在敏捷尚未盛行,職能分工當道的時代,這些似乎都是測試團隊的死穴。

而在他們眼里,只要能找到一位具有豐富架構經驗的 ‘冤大頭’,并組建一個測試架構部,這些問題應該都會迎刃而解。

就這樣,我稀里糊涂的成為了那個 ‘冤大頭’。

之前也曾與朋友聊起過這段經歷,有朋友說,這些問題用敏捷和DevOps就能解決,用不起來是企業文化的問題,找誰來都只能填坑,起不了什么作用。

一切脫離時代背景的評價,都是耍流氓。

在當時,知道敏捷的人不少,了解DevOps的人也挺多,但真正能體系化將這兩樣東西落地的企業卻很少。理論大家都懂,但如何在現有基礎上逐步實踐落地,并取得想要的成果,沒一個人能說的明白。

而且,伴隨著交付壓力的增大,研發與測試之間的交流越來越少,所以想通過一些方法,打通交流的障礙。

第一階段:應用與基礎的測試分離

在入職后的半年里,我的主要工作是參與各測試團隊的工作,一來混熟人頭,二來熟悉業務與現有工作模式。

半年后,我開始與測試總監一起,針對一系列問題進行改進。

先來說說組織結構。

大智慧的系統是建立在C/S架構之上的,所以研發被天然的分割成 “前端” 與 “后端”,又因公司業務分為 “股票實時行情” 與 “金融數據服務” 兩個板塊,把 “后端” 分為行情服務端與數據服務端。

當時的組織架構采取的是職能式組織模式,既然研發被分成為三個團隊,測試也只能緊隨其后。

與客戶端、行情服務端相比,數據服務端的問題就顯得非常多。

以上交所Level-2行情為例,業務場景固化,無論接入協議,還是數據加密,都是非常公開且成熟的技術,而且需求變更少,改動不頻繁,只要沒有新市場接入,一年到頭幾乎沒幾個需求。

反觀數據服務端,連續幾年公司都重金投入,不僅先后并購了幾家數據供應服務商,還對外喊出了 “天天發版” 的口號,氣勢一浪高過一浪。

這下可苦了研發與測試的小伙伴們,由于并購的公司技術棧各有不同,這家用SQLServer,那家就用MySQL,這家用Java,那家就用C++,環境與集成類的問題層出不窮,為了趕進度,只能胡子眉毛一把抓,管他什么應用還是框架,拼湊拼湊,跑通了就上,報錯?拉下來改改,接續上。

一般說,遇到這種緊耦合的情況,就只剩 “拆” 這一條路。

為了不對現有業務的迭代速度造成影響,與研發團隊設立了兩條拆分原則:

  • 原有業務:如有需求調整,強制遷移至新架構,并將基礎與應用進行分離。
  • 新增業務:基于新架構,并將基礎與應用進行分離。

經過半年的折騰,無論老業務還是新業務,大部分核心部分基本都已遷移至新架構上。

隨即,數據服務測試團隊也被拆分成 “基礎測試” 與 “應用測試”,一個保障基建,一個保障業務。

就因這一波操作,經公司領導決定,將 “基礎測試” 與 “應用測試” 劃歸我的名下。

我就這樣,莫名其妙的睡了一覺,醒來的時候變成了測試經理。

第二階段:嘗試集成測試驅動開發

工作與生活差不多,煩心事總是一波接著一波。

某天午后,領導找我談話,說開發、測試與運維之間相互推諉的情況日趨嚴重,想聽聽我有沒有好建議。

咱是讀過孫子兵法的人,一聽就明白了。立即搬出一番DevOps的方案,領導聽了連連擺手,說:“這種大而全的東西少拿來忽悠,來點實際的吧。”

我一愣,想了想說:“要不拿我的兩個團隊來試點,再不改變現有流程的情況,嘗試測試驅動開發怎么樣?”

領導笑了,點了點頭,說:“嗯,你很主動,大膽的去干吧,我支持你!”

尼瑪,我感覺這根本不是談話,分明是挖了個坑讓我自己跳。

什么叫測試驅動開發?

對敏捷比較熟悉的同學,相信一定聽說過TDD(Test-Driven Development)。

大致是說在明確要開發某個功能后,在開發功能代碼之前,先編寫測試代碼,然后編寫功能代碼并用測試代碼進行驗證,如此循環直到完成全部功能的開發。

在技術圈,很多人都討厭這種看似完美的理論,因為與現實中的情況距離太遠。因為還以黑盒測試為主要手段的我們,就單單 “編寫測試代碼” 這一項,就會把我們擋在門外。

所以,我們只能尋找一些適合我們當前技術實力的出路。

與其他公司一樣,我發現大部分的測試爆發點都集中在集成測試階段,舉個例子證實下。

案例:業務系統新上一個A功能,同時涉及客戶端、基礎與應用的修改與新增,結果如何呢?

從這張表中可以明顯看到以下幾點:

  • 各開發都說自己做過了單元測試,并順利通過,所以我沒問題。
  • 各測試都說自己跑過回歸測試,并順利通過,所以我沒問題。
  • 每次提交,客戶端測試都在群里喊,請大家注意配置項的提交,沒人說話。

想起當時有小伙伴調侃過,說每個環節都說自己沒問題,但只要放在一起就出各種問題,難道是機房風水有問題?

顯然不是,那問題究竟出在哪里呢?

又經過半年的折騰,對環境、配置與組織進行了一系列的調整:

我相信一句話,這世界上從來就沒有什么救世主,你強了,你堅信了,困難就變弱了。

到2012年底,我們基本達成 “集成測試團隊驅動開發” 的效果,協助開發進行問題排查,并且取代了項目管理的工作。

又因這一波操作,經公司領導決定,將集成測試團隊也劃歸我的名下。

就這樣,我似乎又睡了一覺,醒來的時候變成了測試副總監。

第三階段:試圖統一流程與工作方式

三國演義開篇說,天下大事,分久必合,合久必分。

隨著棘手問題的逐漸得到緩解,大家開始把注意力放在了流程與規范上。

當時,各測試團隊雖然名義上都歸屬于測試部,但基本都各自為戰,你有你的流程,我有我的套路。

比如上級想得到BUG修復率或提測效率這樣的報告,基本是不可能的。

另外,像測試流程不規范,測試文檔不健全、測試文檔也沒有控制和管理等問題也非常突出。

2013年初,經公司領導決定,將剩余的客戶端、行情服務端這兩個測試團隊合并至我的團隊,成立新測試部門。

我的職務也從測試副總監,升為測試總監。

目標是在年底之前,完成新測試部門的崗位職能、測試流程、測試文檔規范、日常項目工作、部門考評機制以及測試部門人員技能與業務的培訓等多方面的規劃,為公司明年的產品戰略提供更高的質量保障。

回想當時的我,滿腦子裝的都是 “如何幫助研發團隊釋放潛力” 的激進詞匯。一拍腦袋,要求測試所有團隊將工作工具從 “Excel+腳本” 切換到Atlassian下。

或許是這一步邁得太大,而且在整個推進的過程中,我也非常強勢。

就這樣,惹惱了測試團隊中的一些老人,為此還吵過幾次,氣氛開始變得不愉快起來。

細心的朋友可能已經發現,不僅每個階段的涉及范圍都很廣,而且都牽涉到了組織結構的調整,那為什么我還會推動的如此之快呢?

強勢與強壓,是我慣用的兩個手段。

在我心里一直堅信,既然高層把這項艱巨的任務交給我,我就要不惜一切代價搞定。

現在回想起來,我像極了商鞅,改革是成功了,人也得罪光了,有人罩著你的時候,或許一切都顯得順風順水,一旦那個罩你的人不在了,你的死期也就到了。

2013年7月,大智慧已連續虧損幾年,業務低迷,人心惶惶,內部進行了一次結構調整,我受到牽連,被調到了一個新成立的部門,負責新技術的探索。

說白了,就是被踹了,被擼了。

2013年9月,我提交了離職申請,離開了大智慧。

一轉眼,六年過去了。

每次談起這段經歷,我都說,如果上天再給我一次機會重來,我應該會更圓滑一些,至少能讓 “審判日” 來的更晚一些。

人生沒有如果,只有后果和經歷,而經歷卻可以轉化為財富,為將來的職業生涯做好鋪墊。

有的人說,我身上的故事真多,感覺總寫不完。

有的人說,我可以去當編劇,故事編的很溜。

我只想說,我是個搞技術的,不會編故事,只不過天生臭脾氣,遇到的坎坷自然會多一些。

另外,我愿意將這些事情記在心里,再寫出來與大家分享。

如果你也愿意,相信會比我更加精彩。

我還沒有學會寫個人說明!

白話中臺戰略:中臺是個什么鬼?

上一篇

PostgreSQL DBA(31) - Backup&Recovery#4(搭建流復制)

下一篇

你也可能喜歡

我當測試總監的那幾年

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
重庆百变王牌开奖结果