測試流程?項目管理流程?
背景
工作五年了,一直是做測試。認識了很多人大牛,也接觸到很多新人,從他們身上看到了很多,自己的過去,自己的未來(當然很多是自己達不到的高度)。
做這測試這一行的,很多人都追求技術:自動化+性能,往往忽略測試流程,或者說是項目管理流程。
想法
流程是要結合團隊來看的,換句話來說就是case by case,沒有標準,適合團隊/業務的流程就是好流程;
Part1
待過做中國移動項目的傳統行業,測試流程一套一套的,需求評審 -- 開發詳細設計評審 -- 用例評審 -- 提測評審 -- 測試執行 -- 報告輸出 -- 安排上線 -- 線上驗收,很多會議是需要產研測全部參加的,時間投入很大,這原因是因為項目/業務叠代周期是一個月上一次版本,有足夠的時間去做這些,當測試全流程介入的時候確認能發現很多問題,這裏就引入一個詞:質量前移
Part2
回想起唯品會的流程,有很多值得借鑒的地方。
唯品會的流程,核心是火車發布制,項目安排是每個星期發布一個版本,也就是每個星期只有一趟車,項目想上線的話,就需要在指定時間上車,意思就是在規定時間開發測試打包完畢。整個項目的流程就是按照這個火車開車時間來排期規劃。(當然你要問到很多線上問題怎麽辦?緊急項目怎麽辦? 春運不是也有臨時車次這個說法嗎?)
在互聯網行業的話,叠代速度明顯加快,都是你追我趕的節奏,但很多流程也是必須有的。
需求評審會根據需求大小來看是否開展的,小需求的話,就直接是一份文檔查閱就完事了的。
在唯品會的時候,所在團隊有點做的比較好,就是提測環節,我們要求開發提測有輸出,要求他們整理功能點:新增/修改了哪些功能,改動了哪些文件,自測點,自測結果,靜態代碼檢查,單元測試是否全部通過,這些也是測試的一種職責,項目的保證不單單只是測試的事情,測試有義務/責任從整個項目流程中去提升質量。
提測過後,測試要經過冒煙測試,這個冒煙首先要檢查開發的輸出是不是包含了上面提的那些,測試有權利直接打回這次提測,阻塞主流程的問題也要打回,冒煙不通過。冒煙不通過的項目代碼質量堪憂;
功能測試,測試人手一臺測試機器,將項目部署在自己的環境進行功能測試,(這裏講一句,唯品會這方面確實壕,而開發是整個團隊公用一套開發環境,哈哈哈)
回歸測試,功能測試完畢後,需要開發合並代碼到master(最終上線的分支),由於多個項目並行,可能存在代碼合並問題,需要重新再回歸一輪,這個環境可以驗證主幹用例,也可以用自動化去驗證 ,這裏還有一個code review環節;
這裏需要單獨提一點,代碼權限控制,開發合並代碼後,是沒有push代碼的權限了的,代碼權限控制在測試手中,這個時候需要修改代碼,原因為功能測試遺漏,或者是合並代碼錯誤,可以做一個統計;
預發布測試,回歸OK後,打包部署到預發布環境,這個環境都是生產的數據庫了的,重點校驗配置(配置文件,DB...)是否OK,到了這裏也有很多測試不通過的情況,可以做統計數據;
上線驗收,提供給運維最終的包,做上線驗收
唯品會一些細節的流程做的比較好,上線前會有小組的上線評審,這個環節的話,需要說明這個項目有什麽功能;會不會對線上舊功能造成什麽影響;存在什麽風險;是否可以線上驗收,若有怎麽驗收,如果沒有什麽做監控;回滾方案是什麽,集思廣益
需求評審 -- 用例評審 -- 提測 -- 冒煙測試 -- 功能測試 -- 回歸測試 -- 預發布測試 -- 線上驗收 -- 數據監控
Part3
現在的UC,沒有火車發布制度,項目並發更多,很多都是今天提測明天上線的節奏,更加敏捷。一些關鍵流程的缺失會帶來一些風險,但核心點不變,質量前移和監控,這就是看到過一篇文章提到的左移和右移。
團隊也在慢慢加強流程這塊東西了的,質量的保證是整個團隊的事情,測試有業務和責任去提升質量,這裏的質量部分是從項目流程去提升的
小結
測試,不是找bug,應該稱為質量保障,其中的手段就是你職業規劃的路線。
管理,也估計是很多人想走的路線吧,很多人覺得在一家公司混久點就能走上管理層,但我發現在管理層混的好的,都是業務專家,都是會為人處世的,有項目整體風險意識的,當然也需要一定的機遇;
技術,這條路是很多測試同學在走的或者想走的,想搞自動化,想搞性能,因為技術的提升意味著工資的提升,學好一門語言是非常重要的;
不管是做什麽的,自身掌握了稀有資源,待遇自然上去了的。
回到這次的主題:流程,工作經驗的優勢就要凸顯出來,以過往經驗結合現有團隊情況,制定流程,或者對現有流程提出建議;
1. 質量遷移,測試提前介入,從需求端發現問題,帶著問題去開需求評審,懟產品/需求;
2. 合並代碼回歸測試,跟開發溝通後,不要直接上線,需要重新過一遍;
3. 上線評審,思考上線依賴,風險,舊數據/功能影響,回滾方案;
測試流程?項目管理流程?